Pijul, contrôle de version et théorie des patchs, version 0.12

Posté par pmeunier le 24 avril 2019 à 16:05. Édité par ZeroHeure, Nÿco, Davy Defaud et Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

avr.

2019

Pijul est un système de contrôle de version distribué (DVCS) développé en Rust et publié sous licence GPL v2. Il est basé sur une théorie des patches.

La différence principale entre Pijul et Git est que Pijul fonctionne avec des correctifs (ou patches), là où Git ne fonctionne qu’avec des instantané (snapshots). Une branche dans Pijul n’est qu’un ensemble de correctifs.

Ce mode de fonctionnement offre plusieurs avantages, dont une approche sans doute plus conforme à l’usage intuitif d’un DVCS. À ce stade, si vous avez reconnu le fonctionnement de Darcs, vous vous dites : « oui, mais c’est lent ! ». Au départ de Pijul, il y avait l’idée d’améliorer la vitesse de Darcs, mais de nouveaux algorithmes ont permis de créer un outil différent, extrêmement rapide.

La version 0.12 vient de paraître : même s’il reste sans doute quelques problèmes (notamment sur l’espace disque), cette version est le fruit d’importantes refactorisations et simplifications, et est de ce fait bien plus stable et cohérente que les précédentes ; en particulier, tous les algorithmes sont maintenant prouvables mathématiquement.

Aller plus loin

Quelques notes sur cette version (186 clics)
Pijul (674 clics)
Dépôt de code source (262 clics)
Doc : pourquoi Pijul ? (248 clics)

# Difference Pijul vs Git

Posté par cosmocat le 24 avril 2019 à 17:38. Évalué à 10.

La différence principale entre Pijul et Git est que Pijul fonctionne avec des changements (ou patches), là où Git ne fonctionne qu'avec des snapshots (clichés ou versions).

J'ai du mal à vraiment saisir quels sont les avantages intrinsèques à la gestion par patch et ceci comparé à Git.

Car dans les faits, pour des optimisation de place et d'échange entre dépôt, Git stocke aussi dans les pack files des "diffs" (donc des patchs), c'est juste qu'on le voit pas en tant qu'utilisateur.

Mais surtout, pour beaucoup d'opération Git recalcul ces patchs (affichage de logs, rebase, …) pour pouvoir faire certains opérations donc rien de fondamentalement différent de Pijul.

Donc qu'est ce que PiJul permet qui n'est fondamentalement pas possible de faire avec Git qui recalcul les patchs quand cela est nécessaire?

Après, je ne remet pas en cause le fait que le choix d'utiliser des patchs fait que peut-être amène à une interface utilisateur plus cohérente…
- [^] # Re: Difference Pijul vs Git
  
  Posté par pmeunier le 24 avril 2019 à 18:01. Évalué à 10.
  Donc qu'est ce que Pijul permet qui n'est fondamentalement pas possible de faire avec Git qui recalcul les patchs quand cela est nécessaire?
  
  Pijul permet deux choses que Git ne peut pas faire:
  - Dans Pijul, les patchs sont associatifs, ce qui veut dire que si on applique un patch A, puis B et C, on obtient le même résultat qu'en appliquant A et B, puis C. C'est assez intuitif, mais Git n'a pas cette propriété. Concrètement, ça veut dire que Git peut parfois prendre des lignes qui viennent de la fin du fichier, et les merger au début du fichier. Ça ne garantit pas que tous les merges donnent du code qui marche, mais au moins il y a une vraie structure mathématique, ce qui veut dire que le comportement est conforme à l'intuition.
  - Dans Pijul, deux patchs qui peuvent être produits en parallèle commutent toujours, et ça change tout. La commutation élimine complètement le besoin de rebaser, et le cherry-picking devient l'opération par défaut, de manière complètement transparente. Par exemple, on peut cherry-picker plusieurs fois depuis la même branche sans craindre de ressusciter des conflits. La commutation de patchs élimine aussi largement l'utilité des branches, qui servent la plupart du temps dans Git à simuler la commutation de changements indépendants.
  Pijul a aussi une vraie représentation interne des conflits, qui rend leur résolution plus facile : ce n'est pas juste un cas particulier bizarre, intermédiaire entre une tentative de merge local et le commit de merge. Dans Pijul, deux personnes avec le même ensemble de patchs voient les mêmes conflits.
  - [^] # Re: Difference Pijul vs Git
    
    Posté par ZeroHeure le 24 avril 2019 à 18:24. Évalué à 10.
    
    À propos, tu noteras qu'on a un peu rallongé ta courte dépêche. On est preneur de beaucoup plus de présentation de ton intrigant logiciel. Ce peut être sous forme d'entretien si tu n'es pas à l'aise pour rédiger.
    
    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
    - [^] # Re: Difference Pijul vs Git
      
      Posté par pmeunier le 24 avril 2019 à 19:40. Évalué à 8.
      
      J'ai vu, merci ! Cette release me donne un peu de confiance pour écrire plus à propos de Pijul que pour écrire du code, donc je vais m'y atteler bientôt !
  - [^] # Re: Difference Pijul vs Git
    
    Posté par Philippe F (site web personnel) le 24 avril 2019 à 20:58. Évalué à 9.
    
    En lisant la doc, ce qui me vient, c'est que en effet, sous Git, dès que tu pète un coup, tu changes le hash de ton snapshot et tu dois passer derrière par des phases de publications, fusion, distribution etc. Pour pas mal de cas triviaux, c'est assez ennuyeux.
    
    Après, de là à justifier un autre DVCS, je reste un brin sceptique. Même mercurial qui tenait bien la route s'est fait enterrer par Git…
    
    Je m'interroge aussi sur un point : il m'a semblé saisir que si deux patchs sont commutatables, les échanger ne change pas l'identifiant du résultat final. Cela veut dire qu'on peut réécrire l'ordre de l'historique d'un projet ? Et si c'est le cas, n'est-ce pas une anti-feature ?
    - [^] # Re: Difference Pijul vs Git
      
      Posté par pmeunier le 24 avril 2019 à 21:46. Évalué à 10.
      Même mercurial qui tenait bien la route s'est fait enterrer par Git…
      
      Mercurial n'apporte pas grand chose par rapport à Git, c'est essentiellement les mêmes algos, avec les mêmes merges, la même gestion des conflits. L'interface est un peu plus facile, mais moins rapide.
      
      Au fait, il y a un GSoC Mercurial cette année pour tenter adopter l'algo de Pijul pour leurs merges.
      
      Cela veut dire qu'on peut réécrire l'ordre de l'historique d'un projet ? Et si c'est le cas, n'est-ce pas une anti-feature ?
      
      Ce n'est pas une anti-feature, pour trois raisons :
      
      D'abord parce qu'on peut rester "en mode Git" (en faisant des tags au lieu des records), c'est-à-dire que si l'ordre est vraiment important, on peut le maintenir si on veut. Dans ce cas, on ne profite pas à 100% de la commutation, dans le sens où on ne va plus pouvoir éditer les vieux patchs indépendamment des nouveaux. Par contre, dans ce cas, on a quand même des merges déterministes, et une algèbre claire et bien définie (ce qui n'est pas du tout le cas dans Git). Les conflits sont aussi gérés proprement (contrairement à Git, qui ne les représente simplement pas en interne).
      
      Ensuite parce que dès qu'on travaille à plusieurs, ou même sur plusieurs choses en même temps, le travail sur un projet n'est pas une suite linéaire de patchs. C'est Git qui a tort sur ce point, la "vraie" histoire est presque toujours plus compliquée.
      
      Dans Pijul, chaque dépôt a sa propre histoire, et Pijul la connaît (pijul log sait l'afficher, par exemple). Mais comme deux ensembles de patchs identiques produisent toujours le même résultat, même dans des ordres différents, l'ordre a largement moins d'importance que dans Git.
      - [^] # Re: Difference Pijul vs Git
        
        Posté par dfroger le 25 avril 2019 à 09:41. Évalué à 1. Dernière modification le 25 avril 2019 à 09:44.
        
        Dans Pijul, chaque dépôt a sa propre histoire, et Pijul la connaît (pijul log sait l'afficher, par exemple). Mais comme deux ensembles de patchs identiques produisent toujours le même résultat, même dans des ordres différents, l'ordre a largement moins d'importance que dans Git.
        
        J'ai du mal à comprendre comment appliquer un ensemble de patchs dans un ordre différent fonctionne. Si le patch A modifie une ligne et que le patch B supprime cette ligne, et que j'applique B puis A, au moment d'appliquer A, pijul "comprend" que la ligne a été supprimée et que le patch A doit être "ignoré"?
        
        (Il faudra que je lise la théorie…).
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par pmeunier le 25 avril 2019 à 10:07. Évalué à 8.
        
        Je me cite dans une réponse antérieure:
        
        Dans Pijul, deux patchs qui peuvent être produits en parallèle commutent toujours
        
        Je vais modifier un peu ton exemple, parce que ton A et ton B ne sont pas productibles en parallèle dans Pijul (donc Pijul ne garantit pas la commutation dans ce cas).
        
        Par contre, si A modifie un paragraphe, et que B ajoute une ligne au milieu de ce paragraphe, tu as raison, il y a bien un problème. Voici comment Pijul le résout :
        
        Pijul manipule un graphe de lignes. Chaque sommet est une ligne, les arêtes ont un statut. Un patch est un ensemble:
        - de nouveaux sommets et arêtes
        - et de changements de statut d'arêtes.
        
        (bien sûr, on peut faire des patchs qui ne font que l'un ou que l'autre)
        
        Appliquer un patch, c'est appliquer ces changements au graphe (avec quelques optimisations pour que l'application d'un patch reste en complexité logarithmique en la taille de l'histoire). Note qu'il n'y a pas moyen de supprimer une ligne, on peut juste changer son statut (par exemple, la marquer supprimée).
        
        Quand Alice ajoute une ligne dans un paragraphe, elle marque implicitement le contexte (j'appelle "contexte" la ligne d'avant et la ligne d'après) de cette ligne comme "vivant", alors que Bob le marque mort. Quand on fusionne les deux, on a un graphe valide, mais les lignes autour de la ligne d'Alice ont des arêtes vivantes et des arêtes mortes qui leur pointent dessus. C'est un conflit. On le signale à l'utilisateur (la façon de faire ça a changé énormément dans la nouvelle version, c'est devenu super simple), et on le laisse résoudre.
        
        Remarque au passage que ce problème va se poser à partir du moment où Alice et Bob ont le même ensemble de patchs, même dans un ordre différent. Cependant, comme le contexte des lignes d'Alice est implicitement marqué vivant (et pas explicitement en rajoutant des arêtes), alors que Bob voit de nouvelles lignes avec un contexte qu'il a explicitement supprimé, la façon de le détecter doit être un peu subtile.
        
        Pourquoi ne pas marquer le contexte explicitement ? Parce que pour faire ça, il faudrait rajouter des arêtes sur toutes les lignes qu'Alice considère vivantes, c'est-à-dire sur tout le fichier. Le patch d'Alice aurait alors tous les patchs qui ont touché au fichier comme dépendances, et donc les patchs ne pourraient commuter (on aurait donc juste un Git un peu plus lent, et avec des meilleurs merges).
        
        Il y a une subtilité, qui a changé beaucoup dans la version 0.12, pour récupérer un patch qui parle du graphe à partir des changements de l'utilisateur dans un fichier.
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par dfroger le 25 avril 2019 à 11:13. Évalué à 1. Dernière modification le 25 avril 2019 à 11:15.
        
        Merci pour les explications.
        
        Quand on dit que l'historique est séquentiel localement dans un dépôt, ça va veut dire les patchs ont un ordre localement dans chaque dépôt?
        
        Si Alice a comme patches P1, P2, P3 et Bob P1, P2, P4, et que Alice veut appliquer P4 et Bob P3, dire que "les patches commuttent toujours", ça veut dire que Alice et Bob se retrouveront soit avec le même "code", soit avec le même conflict à résoudre?
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par pmeunier le 25 avril 2019 à 11:18. Évalué à 4.
        
        Quand on dit que l'historique est séquentiel localement dans un dépôt, ça va veut dire les patchs ont un ordre localement dans chaque dépôt?
        
        Oui, mais c'est plus du gadget d'interface utilisateur qu'autre chose, la théorie ne dépend absolument pas de ça. Dans le futur, on s'en servira aussi pour accélerer les transferts réseau.
        
        Si Alice a comme patches P1, P2, P3 et Bob P1, P2, P4, et que Alice veut appliquer P4 et Bob P3, dirent que "les patches commuttent toujours", ça veut dire que Alice et Bob se retrouveront avec soit "code" avec le même, soit avec le même conflict à résoudre?
        
        Oui, mais je le dirais un peu différemment: en fait je dirais qu'ils se retrouvent avec le même code, même si ce code contient des conflits.
        
        La différence est un peu importante, parce que Pijul représente les conflits comme le cas "normal", il a même un algo pour détecter qu'un fichier est en conflit. Alors que (par exemple) Git ne stocke que des états sans conflits.
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par Jean Parpaillon (site web personnel) le 25 avril 2019 à 11:32. Évalué à 2.
        
        Oui, mais c'est plus du gadget d'interface utilisateur qu'autre chose, la théorie ne dépend absolument pas de ça
        
        Désolé mais avec un tel discours, ton projet est mort. Je le dis en ayant bossé sur pas mal de projets géniaux mais qui n'ont jamais pris car les UI n'étaient pas à la hauteur. J'insiste parce que je connais bien le milieu de la recherche et je trouve vraiment dommage qu'un tas de projets géniaux soient abandonnés à cause de ce discours: "c'est l'utilisateur qui n'a rien compris", "tout ça c'est des problèmes d'UI" (autrement dit pas important).
        
        En tant que développeur, j'ai vraiment autre chose à penser que la théorie d'un des outils que j'utilise 100 fois par jours. Je veux juste qu'il marche et qu'il résolve des problèmes concrets.
        
        Si tu ne veux pas que ton projet finisse au cimetière des projets géniaux mais inutil(isés), donne-nous un exemple concret et ne commence pas la description par dire que git n'utilise pas des patchs, parce que c'est ce que l'utilisateur voit et c'est la SEULE chose qui lui importe.
        
        "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par pmeunier le 25 avril 2019 à 11:54. Évalué à 10.
        
        Désolé mais avec un tel discours, ton projet est mort.
        
        En effet, surtout s'il est mal compris ! En réalité, ces features sont bel et bien implémentées, mais quand on me demande comment marche la théorie, j'essaie de l'expliquer en enlevant le plus possible de couches d'UI.
        
        Par contre, ce n'est pas du tout la façon dont les auteurs de Pijul pensent les choses. Un petit tour sur notre discourse permet de se rendre compte de l'étendue des discussions sur les noms des commandes, leur composabilité, etc.
        
        Pour avoir une UI de bonne qualité, fiable et portable, je suis même allé jusqu'à écrire une implémentation du protocole SSH en Rust !
        
        En tant que développeur, j'ai vraiment autre chose à penser que la théorie d'un des outils que j'utilise 100 fois par jours.
        
        Certes, mais:
        
        Quelqu'un qui pose la question a apparemment ça à penser.
        
        Git te remet le nez dans ses propres algos à chaque fois que tu travailles avec des gens. L'UI catastrophique de Git n'est pas du tout une excuse, bien au contraire.
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par Jean Parpaillon (site web personnel) le 25 avril 2019 à 14:21. Évalué à 0.
        
        En effet, surtout s'il est mal compris !
        
        … et je n'ai toujours pas d'exemple en dehors de ce qui est considéré comme des mauvaise pratiques: commuter des patches (donc réécrire l'historique) ou encore faire des rebase après merge.
        
        Pour avoir une UI de bonne qualité, fiable et portable, je suis même allé jusqu'à écrire une implémentation du protocole SSH en Rust !
        
        Gné ? On ne serait pas dans le syndrome du "not done here" ?
        
        Quelqu'un qui pose la question a apparemment ça à penser.
        
        Je n'ai pas posé de question sur la théorie, je demande: concrètement, dans le cycle de vie d'un logiciel, quel problème pijul est censé résoudre ?
        
        Tiens, je vais commencer. Mon workflow git (assez classique je pense):
        * une branche master
        * nouvelle feature/bugfix: création d'une nouvelle branche, feature/X par exemple
        * rebase régulièrement sur master
        * quand ma feature est prête, merge de feature/X dans master
        * sur master, j'ai bien un commit merge qui me permet de tracer quand la branche a été fusionnée
        
        La plupart des problèmes que je rencontre aujourd'hui sont liés au merge, effectivement. Il me semble que la plupart du temps, des patchs sémantiques régleraient le problème, par exemple quand il les patchs concernent du coding style, du refactoring, etc. D'ailleurs, j'ai cru comprendre que vous avez d'abord essayé d'améliorer git. git est-il si lié que ça au couple diff/patch ?
        
        Suis-je donc le seul à rencontrer ces problèmes ? Pijul le résout-il ? Quel problème concret résout Pijul ?
        
        "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par pmeunier le 25 avril 2019 à 19:46. Évalué à 10.
        
        commuter des patches (donc réécrire l'historique) ou encore faire des rebase après merge.
        
        La seule raison pour laquelle "c'est considéré comme de mauvaises pratiques", c'est justement parce que Git ne permet pas de le faire proprement !
        
        Gné ? On ne serait pas dans le syndrome du "not done here" ?
        
        Non, mais si ça t'intéresse de comprendre, tu peux reposer la même question sans mépris ;-)
        
        D'autre part il faudrait savoir, entre "tu ne fais pas d'UI" et "not done here". Quand on veut une bonne UI il y a parfois des trucs un peu casse-pieds à faire.
        
        Je n'ai pas posé de question sur la théorie
        
        Non, mais @dfroger en a posé une, je lui ai répondu. Un "workflow" de discussion assez classique à mon avis.
        
        Tiens, je vais commencer. Mon workflow git (assez classique je pense):
        
        Si tu es content avec ton workflow et ton git, c'est très bien, garde-le ! Ça a l'air en effet bien adapté à un gros projet qui roule déjà bien, avec des gens qui comprennent bien le problème qu'ils doivent résoudre, et qui prennent le temps d'organiser leur travail avant de commencer, qui travaillent sur des sous-projets bien délimités à l'avance, qui font rarement d'erreurs, et dont les bugs sont assez "locaux", c'est-à-dire pas trop intriqués les uns avec les autres. Si en plus ils ont le temps de réparer les merges et les rebases qui n'ont pas marché automatiquement, et qu'ils valorisent le respect des contraintes techniques de Git (les dites "bonnes pratiques") plus que leur temps de travail, que demande le peuple ?
        
        Pijul essaie de gérer tous les autres cas, qui correspondent en fait assez bien à mon expérience de programmation et d'écriture d'article. Mon expérience est en fait pire, puisqu'elle est souvent la négation de tous ces trucs-là à la fois !
        
        À savoir des gens qui s'attaquent à un problème inconnu, donc difficile à planifier à l'avance, qui travaillent sur des trucs trop durs pour eux, passent leur temps à devoir refactoriser à mesure qu'ils avancent, et dont la résolution d'un bug (1) soit nécessite de creuser assez profond en touchant à plein de choses (parfois seulement pour tester), (2) soit permet d'arriver dans un nouveau cas qui n'était pas géré, ce qui déclenche un nouveau bug. Et souvent, le temps est limité, soit parce que les gens compétents sur les trucs durs sont trop chers pour leur faire perdre du temps sur Git, soit (dans le cas d'un article) parce qu'il y a une deadline, et qu'on préfère faire des maths que faire du Git.
        
        Il y a un coût caché non-négligeable dans ce type de projet, c'est le coût de changer de contexte. Si je suis en train de faire du code ou d'écrire du LaTeX, ça me demande souvent une concentration importante. Si j'ai à réfléchir à mes branches et mes rebases, et à réparer ce qui casse, je dois me remettre dans le problème après avoir réparé, et ça coûte du temps.
        
        La plupart des problèmes que je rencontre aujourd'hui sont liés au merge, effectivement. Il me semble que la plupart du temps, des patchs sémantiques régleraient le problème, par exemple quand il les patchs concernent du coding style, du refactoring, etc.
        
        Le plus gros problème est que le patch minimal n'est pas unique. Par extension, diff3 a parfois plusieurs choix, ce qui est assez inquiétant, parce que Git peut parfois mélanger des lignes un peu n'importe comment.
        
        Suis-je donc le seul à rencontrer ces problèmes ? Pijul le résout-il ?
        
        Non (de très loin), et oui, à 100%, sans patchs sémantiques.
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par barmic le 26 avril 2019 à 18:46. Évalué à 2.
        
        Pour avoir une UI de bonne qualité, fiable et portable, je suis même allé jusqu'à écrire une implémentation du protocole SSH en Rust !
        
        Je ne vois pas le rapport entre SSH et l'UI. En plus tu l'a fais pour des soucis de sécurité de ce que tu disais (et peut être pour la performance en réduisant la latence), pas pour de l'UI ?
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par pmeunier le 27 avril 2019 à 18:47. Évalué à 4.
        
        L'idée était de rendre super l'installation et l'utilisation super simple sur toutes les plateformes. Darcs est difficile à installer sous Windows, parce qu'il faut installer un agent SSH. Git est un peu mieux, mais ce n'est pas non plus évident.
        
        Toutes les versions de SSH ne supportent pas les mêmes morceaux du protocole, et n'ont pas les mêmes options. En plus le fait de pouvoir écrire mon propre serveur avec Thrussh permet une interaction un peu plus fluide avec le Nest, par exemple (les messages d'erreur seront plus faciles à implémenter bien dans le futur).
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par brendel le 14 mai 2019 à 12:11. Évalué à 10.
        
        Tu as probablement raison, mais c'est énervant aussi que à chaque fois que quelqu'un propose un truc cool sur le plan technique ou théorique et essaye de se concentrer dessus il y a toujours quelqu'un pour parler uniquement cas d'utilisation et voir si l'UI est belle/intuitive/keyword à la mode, cela sans regarder beaucoup la partie intéressante.
        
        On est censé être sur un site "technique" avec des gens qui aiment l'informatique alors ça me gène pas qu'on parle que d'informatique et pas d'UI même si c'est plus important pour l'adoption du projet. Si le seul but des articles c'est de trouver des nouveaux tools pour le boulot de tous les jours c'est un peu dommage.
        
        La on a quelqu'un qui s'est penché vraiment sur tous les problèmes de DVCS, la théorie derrière, une explications des nouveaux algos, une vrai comparaison avec git (c'est à dire au niveau de son fonctionnement interne) mais le seul truc intéréssant pour certains c'est "oui mais heu c'est quand que c'est utile et est-ce que j'ai besoin de réfléchir?".
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par dfroger le 25 avril 2019 à 11:52. Évalué à 3.
        
        Quand on dit que l'historique est séquentiel localement dans un dépôt, ça va veut dire les patchs ont un ordre localement dans chaque dépôt?
        
        Oui, mais c'est plus du gadget d'interface utilisateur qu'autre chose, la théorie ne dépend absolument pas de ça. Dans le futur, on s'en servira aussi pour accélerer les transferts réseau.
        
        Quand on pull les patches de quelqu'un d'autres, il faut quand même les pull séquentiellement?
        
        Si Alice a comme patchs P1, A, B (avec A qui modifie une ligne et B qui la supprime, comme dans la question plus haut), et Bob a comme patchs P1, Bob peut pull A et B, mais pas B et A?
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par pmeunier le 25 avril 2019 à 11:56. Évalué à 5.
        
        Oui, bien sûr. Tu n'es pas obligé d'appliquer tout dans le même ordre, mais on ne doit jamais se retrouver dans un état où il manque des dépendances. Donc si B dépend de A (comme dans ton exemple), il faudra appliquer A avant B.
        
        [^] # Re: Difference Pijul vs Git
        
        Posté par dfroger le 25 avril 2019 à 12:09. Évalué à 1.
        
        D'accord. En tout cas, je trouve le projet super, je vais tester!
- [^] # Re: Difference Pijul vs Git
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 25 avril 2019 à 10:25. Évalué à 3.
  
  C’est simple : Git is clearly not a VCS, and it has never tried to be one.
  - [^] # Re: Difference Pijul vs Git
    
    Posté par pmeunier le 25 avril 2019 à 10:42. Évalué à 4. Dernière modification le 25 avril 2019 à 10:42.
    
    Si on suit le raisonnement, Pijul est encore moins un "VCS", parce que dans Git, l'historique est au moins séquentiel, alors que dans Pijul, il ne l'est que localement dans chaque dépôt.
# Déplacement de données ?

Posté par karteum59 le 24 avril 2019 à 21:08. Évalué à 8. Dernière modification le 24 avril 2019 à 21:12.

Une chose (parmi d'autres) que j'ai toujours un peu déplorée dans les outils de diff/patch est la sémantique plutôt pauvre concernant le déplacement de données, qui est vue comme un ajout+suppression plutôt qu'avec un opcode décrivant le déplacement. Certains outils comme Meld sont capables d'afficher (plus ou moins bien) des déplacements en interprêtant l'ajout+suppression comme tel, et l'existence d'outils de diff alternatifs montre que ça devrait être possible (mais n'est intégré au niveau de GNU Diff ou de git).

Autre chose en lien (ou pas) : j'ai eu régulièrement des soucis avec git lors du renommage/déplacements de fichiers ou de dossiers (même en faisant attention à ne pas mélanger ça avec un commit "habituel") : plusieurs fois la détection "automagique" du renommage/déplacement ne marchait pas et je perdais l'historique dudit fichier…

P.S. je ne suis pas un grand codeur donc peut-être que c'est simplement le résultat d'une méconnaissance de l'outil ou d'une mauvaise utilisation, mais en comparaison avec git ce serait cool si pijul pouvait 1°/ être fiable (comme bazaar) pour le suivi du déplacement de fichiers et 2°/ avoir un format de patchs qui garde l'information concernant les blocs déplacés au sein d'un même fichier (ou entre fichiers, si c'était envisageable. Bref j'aimerais qu'un C-X C-V au sein du fichier ou entre différents fichiers soit encodé comme "tel bloc de données à été déplacé de X vers Y" et non comme un ajout+suppression…), mais j'ignore si c'est compatible avec ta théorie des patch et avec le format de données que tu envisages :), 3°/ cerise sur le gâteau : j'aime plutôt bien fossil pour sa simplicité et le fait que le repo entier est dans un unique fichier qui est une base sqlite : est-ce envisageable dans ton cas ?

(en fait pour aller plus loin : imaginons qu'on conçoive un outil de diff/patch intégrant l'opcode "déplacement de bloc" mais par exemple aussi "indentation de bloc", "renommage d'une variable/refactoring", "suppression des espaces blancs" et d'autres choses => cela change t-il quelque chose à ta théorie des patchs ?)
- [^] # Re: Déplacement de données ?
  
  Posté par pmeunier le 24 avril 2019 à 22:00. Évalué à 7.
  
  1°/ être fiable (comme bazaar) pour le suivi du déplacement de fichiers
  
  Il n'y a rien de magique ou d'heuristique dans Pijul, tout est basé sur des maths, et est déterministe (il peut y avoir des bugs, quand même).
  
  Donc Pijul est même plus fiable là-dessus que Bazaar, parce qu'il gère proprement les conflits de déplacements fichiers.
  
  2°/ avoir un format de patchs qui garde l'information concernant les blocs déplacés au sein d'un même fichier (ou entre fichiers, si c'était envisageable. Bref j'aimerais qu'un C-X C-V au sein du fichier ou entre différents fichiers soit encodé comme "tel bloc de données à été déplacé de X vers Y" et non comme un ajout+suppression…), mais j'ignore si c'est compatible avec ta théorie des patch et avec le format de données que tu envisages :),
  
  J'aimerais bien avoir ça aussi, mais malheureusement, ça change pas mal la théorie : qu'est-ce qu'on est censé faire si Alice déplace un bloc vers le fichier A, pendant que Bob déplace le même bloc vers le fichier B en parallèle ?
  
  On peut certainement ruser un peu dans pas mal de cas, mais l'idée de Pijul est de faire une théorie mathématique, c'est-à-dire une solution générale qui gère 100% des cas.
  (par exemple aussi le cas où Charlie édite le même bloc sans le déplacer, en parallèle d'Alice et Bob).
  
  3°/ cerise sur le gâteau : j'aime plutôt bien fossil pour sa simplicité et le fait que le repo entier est dans un unique fichier qui est une base sqlite : est-ce envisageable dans ton cas ?
  
  Je ne trouve pas Fossil simple, je le trouve simpliste (je préfère Git et Mercurial). J'ai du mal à voir pourquoi SQLite est un bon choix pour faire ça, j'ai plutôt l'impression que c'est Fossil qui est un bon choix pour illustrer SQLite.
  
  Notre backend est aussi une base de données (Sanakirja, dont j'ai aussi écrit un bon morceau), mais largement plus rapide que celle de SQLite, et avec une feature cruciale pour implémenter des branches sur une base de données sans faire aucune copie.
  
  Et faire tenir tout dans un seul fichier est un peu contraire à l'idée de pouvoir échanger plein de petits patchs indépendants. Mais si tu n'as pas l'intention de pousser ou d'unrecorder des patchs, tu peux toujours garder juste le fichier .pijul/pristine/db et effacer tout le reste, ton dépôt marchera sans doute encore.
  
  (en fait pour aller plus loin : imaginons qu'on conçoive un outil de diff/patch intégrant l'opcode "déplacement de bloc" mais par exemple aussi "indentation de bloc", "renommage d'une variable/refactoring", "suppression des espaces blancs" et d'autres choses => cela change t-il quelque chose à ta théorie des patchs ?)
  
  Darcs fait une partie de ces choses. L'indentation ou les espaces, ce serait plutôt facile à ajouter dans Pijul, pour le reste j'ai un peu réfléchi à la question, et ça n'a pas l'air complètement évident : encore une fois, que doit-on faire si Alice et Bob décident en parallèle de renommer la même variable avec deux noms différents ?
  - [^] # Re: Déplacement de données ?
    
    Posté par kantien le 26 avril 2019 à 11:07. Évalué à 3.
    
    encore une fois, que doit-on faire si Alice et Bob décident en parallèle de renommer la même variable avec deux noms différents ?
    
    Il y a conflit ? Le merge est un graphe qui n'est pas une liste et il y a conflit à résoudre.
    
    Si j'ai bien compris les principes derrière pijul, il y a au fond deux opérations primitives commit : patch -> graggle -> graggle et merge : graggle -> graggle -> graggle. Elles ont de bonnes propriétés algébriques, de telles sorte que le graphe ci-dessous commute :
    
    Mais comme tu le dis dans un autre commentaire, pijul n'a pas besoin de patchs sémantiques pour fonctionner correctement. À la rigueur, cela pourrait être utile pour l'UI et fournir des informations plus détaillées à l'utilisateur lorsqu'il doit résoudre un conflit.
    
    Dans le fond, ces patchs sémantiques sont juste une subdvision du type des patch (des sous-types) mais l'essentiel pour pijul c'est que ce soit des patchs. N'est-ce pas cela ? Dans ce cas, la seule chose que cela peut apporter serait d'ajouter des tags sur les patchs (comme les différentes variantes d'un type somme sont tagguées par un compilateur) et s'en servir pour adapter les messages au niveau de l'interface utilisateur, mais sans rien modifier sous le capot au niveau de la gestion des fusions et conflits.
    
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
    - [^] # Re: Déplacement de données ?
      
      Posté par pmeunier le 26 avril 2019 à 11:20. Évalué à 2.
      
      Il y a conflit ? Le merge est un graphe qui n'est pas une liste et il y a conflit à résoudre.
      
      Justement pas trop, parce que le renommage ne produit pas juste une liste. Une façon de le représenter serait de rajouter un fichier "dictionnaire" à côté de chaque fichier. On représenterait toutes les variables dans le fichier original par des numéros, et le dictionnaire traduirait. Mais ce n'est pas trop ça.
      
      Je ne suis pas sûr de savoir ce que sont les graggle, j'imagine que c'est le graphe des lignes. Tu as effectivement bien compris : le merge de O.p et O.q dans ton diagramme donne la même résultat que O.q.p et O.p.q.
      - [^] # Re: Déplacement de données ?
        
        Posté par kantien le 26 avril 2019 à 12:11. Évalué à 8.
        
        Je ne suis pas sûr de savoir ce que sont les graggle, j'imagine que c'est le graphe des lignes.
        
        Oui c'est cela, c'est le nom que leur a donné Joe Neeman. J'avais lu ces articles de blog pour comprendre la théorie derrière pijul, sans avoir à me farcir les articles académiques.
        
        Justement pas trop, parce que le renommage ne produit pas juste une liste.
        
        Là je ne comprends pas trop. Il y a d'autres forme de graphes que les listes pour représenter un état sans conflit ?
        
        Pour ce qui est du dictionnaire de renommage, pourquoi ne pas le mettre comme tag sur le patch ? En admettant qu'il soit facilement décidable à quel sous-type de patch on a affaire : pijul remarque que A propose un patch de renommage, de même que B, et il marque chacun des patch avec leur dictionnaire. Puis lors de la résolution de conflit, pijul spécifie la cause du conflit (conflit de renommage) et propose une solution spécifique : choisir les noms de A ou ceux de B.
        
        Si j'ai bien compris l'idée des patchs sémantiques, le principe est d'avoir un type générique patch avec plusieurs sous-type (déplacement, renommage, indentation…). Le problème étant, en autre, de savoir s'il est facilement décidable de savoir à quel sous-type appartient un patch donné. Mais, si c'est le cas, l'information devrait être attachée au patch et non au graphe de ligne.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Soit j'ai rien compris soit...

Posté par Jean Parpaillon (site web personnel) le 25 avril 2019 à 09:48. Évalué à 1.

La différence principale entre Pijul et Git est que Pijul fonctionne avec des changements (ou patches), là où > Git ne fonctionne qu'avec des snapshots (clichés ou versions). Une branche dans Pijul n'est qu'un ensemble de > patches.

Euhm vous êtes sûrs de ce que vous dites ? Parce que la gestion par versions / snapshots c'est CVS et SVN. La gestion par patches c'est git (et ensuite mercurial, etc).

Du coup quelle est la vraie innovation de pijul ? Le fait que la commutation de patch ne change pas l'identifiant d'une version ? Ça serait plutôt un recul. Avec git, si je modifie l'historique, le hash de la version change, et c'est exactement ce qu'on attend d'un système de contrôle de version fiable et immuable.

Développez svp :)

"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
- [^] # Re: Soit j'ai rien compris soit...
  
  Posté par Matthieu Moy (site web personnel) le 25 avril 2019 à 09:57. Évalué à 10.
  
  La gestion par patches c'est git (et ensuite mercurial, etc).
  
  Non, Git et Mercurial sont tous les deux snapshot-oriented. Si tu parles du commit 14c0f8d3ab6c36672189cd2dd217f4617d12ccba dans Git, il n'y a qu'un état du projet possible pour ce commit, et c'est d'ailleurs à partir de cet état que la chaîne de caractères 14c0f8d3ab6c36672189cd2dd217f4617d12ccba est calculée (en gros un sha1sum du contenu du projet). L'identifiant de commit ne représente pas le changement introduit par le commit, mais l'état du projet après ce changement. Si tu veux un patch, tu dois (enfin, git doit) le reconstruire en comparant le commit et son parent (ou ses parents si c'est un merge).
  
  D'ailleurs, le format de stockage par défaut de Git (avant un git gc) stocke tous les fichiers sans faire de diff.
  - [^] # Re: Soit j'ai rien compris soit...
    
    Posté par Philippe F (site web personnel) le 25 avril 2019 à 20:21. Évalué à 2.
    
    Pour Git, je suis d’accord, mais pour Mercurial, il me semble qu'il stocke justement un ensemble de patch et que le sha porte sur les patches qui permettent d'arriver à une version donnée.
    - [^] # Re: Soit j'ai rien compris soit...
      
      Posté par Matthieu Moy (site web personnel) le 26 avril 2019 à 10:13. Évalué à 4.
      
      Bien sûr qu'il y a de la delta-compression dans le stockage de Mercurial. Dans celui de Git aussi dès que tu utilises des packs (ce qui se fait automatiquement après quelques commits). Mais c'est uniquement une question d'utilisation d'espace disque (de même que si je fais un ZIP d'un répertoire, ZIP ne va pas forcément re-stoquer tous les fichiers en entier en pratique, mais les données restent là). Le modèle conceptuel reste celui d'un ensemble de snapshots. Par exemple, les hash sont calculés de la même façon (Mercurial hashes both the contents of an object and the hash of its parents), et ce sont eux qui identifient les objets et donnent toute la structure interne du dépôt.
- [^] # Re: Soit j'ai rien compris soit...
  
  Posté par pmeunier le 25 avril 2019 à 10:20. Évalué à 6.
  
  J'ai déjà répondu à une partie de cette remarque hier, ici même.
  
  Git ne travaille pas avec des patchs, il en stocke parfois (uniquement pour des raisons de performance, ce sont les packfiles). Par contre, c'est vrai que Git n'expose pas ses entrailles à l'utilisateur "normal", et préfère montrer des patchs, parce que les patchs sont plus intuitifs que les commits (eh oui ! on n'a pas non plus écrit Pijul, Sanakirja, Thrussh… juste pour le plaisir).
  
  Du point de vue purement théorique (en ignorant tout les outils qui vont autour), Git et Mercurial ne différent vraiment de SVN que par la possibilité de faire des branches. C'est une super innovation, qui enlève notamment le besoin d'avoir un serveur, et permet d'aller un peu plus vite.
  
  Il y a d'autres changements massifs entre SVN et Git, par exemple la façon dont Git représente les dépôts est vraiment simple et élégante, alors que SVN avait une représentation toute pourrie (même Pijul a besoin d'une représentation assez tordue pour arriver à ses fins).
  - [^] # Re: Soit j'ai rien compris soit...
    
    Posté par windu.2b le 25 avril 2019 à 11:10. Évalué à 2.
    
    Du point de vue purement théorique (en ignorant tout les outils qui vont autour), Git et Mercurial ne différent vraiment de SVN que par la possibilité de faire des branches. C'est une super innovation, qui enlève notamment le besoin d'avoir un serveur, et permet d'aller un peu plus vite.
    
    Euh… SVN permet aussi les branches ! C'est juste qu'elles sont lourdes à manipuler (recopie complète de trunk).
    Pour moi, l'innovation principale de Mercurial/Git par rapport à SVN, c'est d'être totalement indépendant d'un serveur central : pas de dépendances réseaux empêchant les commits, possibilité de faire des commits locaux, même quand on n'a pas les droits d'écriture sur le dépôt officiel (les contributeurs à des projets libres ont dû apprécier), …
    - [^] # Re: Soit j'ai rien compris soit...
      
      Posté par Blackknight (site web personnel, Mastodon) le 25 avril 2019 à 11:18. Évalué à 5.
      
      Euh… SVN permet aussi les branches ! C'est juste qu'elles sont lourdes à manipuler (recopie complète de trunk)
      
      ?? Les branches ne sont qu'un lien vers le point de départ dans la révision donnée mais clairement pas une copie complète.
      C'est d'ailleurs pour ça que la création de branche sur SVN est quasi immédiate (cf. Cheap copies).
  - [^] # Re: Soit j'ai rien compris soit...
    
    Posté par Jean Parpaillon (site web personnel) le 25 avril 2019 à 11:17. Évalué à -2.
    
    J'ai bien lu la réponse précédente mais je me suis permis de réitérer la question parce que je ne comprend toujours pas l'intérêt concret (je ne dis pas qu'il y en n'a pas, juste que l'argumentaire n'accroche pas sur ma pratique régulière de git).
    
    Déjà, que git utilise en interne autre chose que ce que je vois, peu importe: en tant qu'utilisateur, c'est ce que je vois qui m'importe. Après tout "under the hood", pijul et git ne sont pas vraiment différents, ils utilisent des fichiers, des bits, des octets ou des signaux électro-magnétique…
    
    De plus, pijul permet la commutativité des patchs ? La belle affaire: ça ne m'intéresse pas, bien au contraire. La qualité et la sécurité du code exige que l'historique des sources soit immuable. Essaierait-on de me vendre l'eau tiède ?
    
    Bref je suis curieux, intéressé, mais je ne vois toujours pas l'intérêt pratique. Un exemple dans la vraie vie ?
    
    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
    - [^] # Re: Soit j'ai rien compris soit...
      
      Posté par pmeunier le 25 avril 2019 à 11:46. Évalué à 7.
      
      Déjà, que git utilise en interne autre chose que ce que je vois, peu importe: en tant qu'utilisateur, c'est ce que je vois qui m'importe.
      
      C'est un peu faux : si Git te montre des patchs, c'est qu'il sait qu'on a du mal à travailler avec autre chose !
      
      Si les patchs étaient une représentation fidèle, dans 100% de cas, de ce qu'il y a dessous, ton commentaire serait vrai : d'ailleurs Pijul représente sa structure interne de manière un peu tordue, mais cette représentation est en bijection avec l'ensemble des patchs appliqués dans le dépôt.
      
      Ce n'est pas le cas dans Git, où certains commits ne sont pas représentables par des patchs (des commits de fusion de branches, de résolution de conflits…).
      
      La différence est loin d'être anecdotique : c'est justement dans les cas difficiles qu'on a besoin d'un bon système de contrôle de versions intuitif et déterministe, pas quand tout va bien, que l'historique est linéaire, qu'il n'y a jamais ni conflits ni rebases ni fusions.
      
      La belle affaire: ça ne m'intéresse pas, bien au contraire.
      
      Je n'y crois pas trop : sauf si tu utilises Git seulement dans ton coin en travaillant sur un seul bout de ton code à la fois, tu essaies de simuler la commutativité tout le temps avec Git, en utilisant des feature branches. Parfois ça marche, parfois il faut passer un temps plus ou moins important à rebaser.
      
      Par exemple, plein d'utilisateurs un peu expérimentés de Git ont des astuces pour utiliser autre chose que git pull (qui vont de git pull --rebase à git fetch + git merge, et autres git rerere s'il y a un conflit), simplement parce qu'ils savent qu'ils ne vont plus jamais pouvoir faire commuter quoi que ce soit une fois le commit terminé.
      
      La qualité et la sécurité du code exige que l'historique des sources soit immuable.
      
      En fait "dans la vraie vie" c'est plus compliqué que ça. Dans Git, l'historique des sources devient artificiel à partir du moment où on rebase des trucs, ce qui arrive assez souvent quand on travaille à plusieurs, et/ou sur un projet un peu gros ou un peu compliqué. En forçant un historique identique pour tout le monde, Git oublie l'ordre local dans lequel on a travaillé, et oublie les relations de dépendances.
      
      En plus, en forçant un historique séquentiel sur une branche donnée, Git force son utilisateur à organiser son travail en amont, alors qu'on sait bien qu'on ne travaille pas toujours sur du code selon un ordre établi à l'avance, en particulier quand on cherche à corriger un bug.
      
      Si on parle de sécurité, je ne trouve pas très sécurisant d'avoir un algo de merge (tous ceux de Git ont ce problème) qui peut mélanger des lignes venant des deux branches un peu aléatoirement. Par contre, je serais content de pouvoir virer un vieux patch qui avait introduit une faille de sécurité, tout en gardant ce que j'ai fait après.
      
      En résumé, je pense que "La qualité et la sécurité du code exigent":
      - que les algos qui manipulent le code soient déterministes, prévisibles, et qu'on puisse les inverser si on fait une erreur. Git n'a aucune de ces propriétés à 100% (mais essaie de les avoir assez souvent).
      - qu'on puisse savoir exactement ce qu'on envoie en production. Mais il n'y a pas besoin de version immutables tout le long du développement pour ça, bien au contraire, il suffit de pouvoir identifier un truc qui fonctionne.
    - [^] # Re: Soit j'ai rien compris soit...
      
      Posté par jyes le 25 avril 2019 à 12:01. Évalué à 7.
      La belle affaire: ça ne m'intéresse pas, bien au contraire.
      
      Eh bien ne l’utilise pas. Mais la commutativité me semble un atout considérable. Quand on travaille à plusieurs sur un dépôt, et qu’on fait vivre plusieurs branches en parallèle, ça arrive très régulièrement de devoir résoudre les conflits de multiples fois, juste parce que Git ne conserve pas la notion de conflit (en fait de patch) mais uniquement les fichiers après résolution des conflits. Si je pouvais éviter toutes ces manipulations inutiles en changeant de DVCS, je le ferai(s)¹ avec plaisir !
      
      Encore au conditionnel car pour bosser à plusieurs, c’est pratique d’utiliser un outils aussi hégémonique que Git, mais je testerai Pijul, c’est certain. ↩
      - [^] # Re: Soit j'ai rien compris soit...
        
        Posté par robin le 30 avril 2019 à 16:55. Évalué à 3.
        
        Il me semble que les versions récentes de git gère ça comme il faut. Si tu fait un rebase, il me semble qu'il utilise git rerere sous le capot pour enregistrer la méthode de résolution d'un conflit, et grâce à ça, il peut réappliquer cette résolution sur des conflits similaire futurs.
        
        bépo powered
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 30 avril 2019 à 17:24. Évalué à 3.
        
        Git ne gère pas vraiment ça dans 100% des cas, mais tu as raison, on voit qu'il aimerait bien simuler la commutation des patchs :
        
        Dans le cas des conflits, Git rerere ne se souvient pas vraiment du conflit, parce qu'il n'y a pas de représentation des conflits propre dans Git. Un conflit, c'est un merge qui n'a pas marché, il faut le résoudre. Git rerere est une heuristique pour essayer de se rappeler comment on a résolu la première fois, et ça marche dans plein de cas. Mais même si Git a des heuristiques qui marchent sans doute bien sur les exemples simples, il lui manquera de toute façon des informations.
        
        La commutation ne sert pas qu'à résoudre des conflits, ça sert aussi à éviter d'avoir à organiser son travail à l'avance très précisément. Il y a des cas (soit très simplifiés, soit très rigoureux) où ce n'est pas nécessaire. Dans tous les projets où je suis impliqué, c'est crucial. La seule exception (dans mon cas) est peut-être nixpkgs, mais même là, j'aimerais bien pouvoir composer mes versions comme je veux, sans avoir à perdre des heures dans des merges et des rebases que je vais devoir de toute façon défaire au bout d'un moment quand mes PR seront acceptées.
  - [^] # Re: Soit j'ai rien compris soit...
    
    Posté par FantastIX le 26 avril 2019 à 10:28. Évalué à 3.
    […] les patchs sont plus intuitifs que les commits […]
    
    Euh… pardon? Je ne comprends pas cette affirmation. C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.
    
    Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif. Les trois sont intuitifs, quand on a déjà des références, ce qui ne doit pas être impossible, surtout pour un développeur. Ça ne signifie pas nécessairement que ces termes sont interchangeables mais que leur compréhension est assez aisée.
    
    Sinon, je pense que cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités. Qu'on appelle ce "truc" un "patch", un "commit", un "snapshot", quelle importance? Ce que demande un développeur, AMHA, c'est que l'outil fonctionne, qu'il lui donne satisfaction et lui permette de faire ce qu'il désire sans se prendre le chou. Maintenant, que ce soit à travers des "patches", des "commits", des "snapshots", des "branches", des "rebase"… tout ça c'est juste du formalisme à se farcir. Pour tirer le meilleur parti d'un outil, il faut maîtriser son utilisation — oui, le vocabulaire en fait partie.
    
    En ce qui concerne un outil de gestion de code source — je parle pour moi — tout ce qui m'intéresse, c'est, par exemple:
    - est-ce que je peux l'apprendre tout seul comme un grand et l'utiliser?
    - est-ce qu'il me sauvegarde mes modif's sans me prendre la tête?
    - est-ce qu'il me fournit un historique de ce que j'ai fait?
    - est-ce qu'il me permet de naviguer dans mes révisions?
    - est-ce qu'il me permet de défaire ce que j'ai fait?
    - est-ce qu'il me permet de regrouper des changements?
    - est-ce que je peux récupérer des modif's, individuelles ou groupées?
    - est-ce qu'il est disponible au moins sur Windows, Linux et Mac, que je puisse partager du code avec n'importe qui?
    Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet. En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel et, si vraiment je suis bouché, je trouve sur StackOverflow. Ou ailleurs.
    
    Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git. Et il y a beaucoup de cerises sur le git-eau…
    
    A priori Pijul ne donne pas de motif suffisant à changer par rapport à Git. Je pense que c'est l'un des points abordés par Jean Parpaillon dans ses commentaires.
    
    Ceci dit, c'est très bien que des outils comme ça naissent aussi. Après tout, c'est aussi un des [nombreux] aspects du logiciel libre. Avoir plus d'un point de vue, éclairé ou pas, que chacun puisse faire son choix, en toute liberté, c'est bien. Après, c'est la nature [humaine] qui décide ;-) …
    - [^] # Re: Soit j'ai rien compris soit...
      
      Posté par jyes le 26 avril 2019 à 11:46. Évalué à 8.
      
      […] les patchs sont plus intuitifs que les commits […]
      
      Euh… pardon? Je ne comprends pas cette affirmation. C'est comme affirmer "un dessin est plus intuitif qu'un crayon"
      
      Non, tu penses que « cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités » mais tu ne cherches ni à comprendre pourquoi l’auteur fait une différence dans son vocabulaire ni à voir en quoi cette différence est à l’image des objets différents que manipulent Git et Pijul. Un « commit » au sens de Git, c’est un enregistrement de l’état complet de l’espace de travail (un « snapshot », un « cliché » pour reprendre ta liste de synonymes). Un « patch » au sens de Pijul, c’est un ensemble de modifications à l’état de l’espace de travail.
      
      Des modifications qui ne se marchent pas sur les pieds les unes des autres peuvent donc commuter dans Pijul. Git, pour afficher des patchs, recalcule en fait le différentiel entre deux commits mais il ne connaît qu’une liste d’états (les commits) qui évidemment eux ne commutent pas. Cette différence fondamentale est la cause qui fait que dans Git, quand tu rebases une branche sur une autre et que tu résous des conflits, si tu rebases une deuxième fois, tu risques de devoir résoudre à nouveau les mêmes conflits.
      
      Et pour faire court, oui « les patchs sont plus intuitifs que les commits », d’ailleurs Git affiche bien des patchs (même s’il stocke des commits) et un bon commit qui respecte les bonnes pratiques regroupe un ensemble de modifications cohérentes pour apporter une fonctionnalité ou résoudre un bogue. C’est donc bien un objet patch que la programmeuse veut manipuler, et les rouages internes de Git lui montrent de temps en temps que ce n’est pas le cas en la forçant à gérer les conflits de manière non-optimale.
      - [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 03 mai 2019 à 15:06. Évalué à 2.
        
        […] tu ne cherches ni à comprendre pourquoi […]
        
        Ce que tu fais là s'appelle un procès d'intention. Soyons clairs, d'abord tu n'es pas dans ma tête; tu ne peux donc savoir ce que je cherche — ce que j'ai écrit n'en constitue pas l'expression intégrale et tu disposes de trop peu d'information pour te faire une idée rigoureuse de ce que j'ai en tête et de ce que je cherche exactement.
        
        Ensuite, si j'ai proféré cette affirmation, c'est tout simplement pour exprimer que je ne comprends pas celle de l'auteur. Après, que tu te méprennes sur mes intentions, ma foi, je n'ai pas demandé explicitement que l'auteur éclaircisse ses propos, c'est exact. S'il le fait (et c'est d'ailleurs le cas dans son commentaire plus bas), alors tant mieux et merci à lui.
        
        Finalement tu m'expliques ce qu'est un commit pour Git (ce que je sais déjà) et ce qu'est un patch au sens de Pijul. Merci bien, mais ça n'éclaire pas ma lanterne en quoi l'un peut être plus (ou moins) intuitif que l'autre.
        
        Un commit et un patch sont deux choses totalement distinctes, que l'on ne peut comparer — un cliché (ou un commit) est un moyen pour Git d'arriver au résultat souhaité, un patch, le second est donc le résultat du premier. Donc dire que l'un est plus intuitif que l'autre, ça n'a pas de sens pour moi.
        
        Si je suis arrivé à cette conclusion, c'est donc qu'il n'y a aucune ambiguïté en ce qui me concerne — je répète: je parle pour moi, je ne prends pas mon cas pour un généralité. Voilà pourquoi j'ai affirmé ne pas comprendre ce qui amenait l'auteur à dire ça.
    - [^] # Re: Soit j'ai rien compris soit...
      
      Posté par pmeunier le 26 avril 2019 à 12:04. Évalué à 9.
      
      C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.
      
      Je te suggère d'imaginer que tes interlocuteurs ne sont pas en train de délirer, et essaient vraiment de proposer un truc autre qu'un changement de vocabulaire.
      
      Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif.
      
      Ok, on va donc parler vocabulaire : un patch pour nous, c'est un ensemble de changements quelconque. On pourrait aussi dire un "diff". Laisser tomber tes préjugés deux minutes le temps de lire la dépêche aurait suffi à s'en rendre compte.
      
      leur compréhension est assez aisée.
      
      Non, plein d'utilisateurs de Git pensent que Git travaille avec des diffs, et ne comprennent pas toujours son comportement à cause de ça. Les commits ne sont "assez aisés" à comprendre que quand ils sont simples, qu'il n'y a pas ni conflits ni nécessité de rebaser.
      
      tout ce qui m'intéresse, c'est, par exemple:
      
      J'ai l'impression qu'on a les mêmes intérêts, et que c'est même pour ça que je pense qu'on peut faire mieux que Git:
      
      est-ce que je peux l'apprendre tout seul comme un grand et l'utiliser?
      
      Je rajouterais "en un temps raisonnable". Pour ça je prétends que travailler avec des diffs/patchs est largement plus facile à apprendre, d'abord parce qu'il y a un concept de moins (les commits), et surtout parce que le concept qui reste (les diffs) est très intuitif et très souple à utiliser (et d'ailleurs, c'est ce que Git montre à l'utilisateur).
      
      est-ce qu'il me sauvegarde mes modif's sans me prendre la tête?
      
      Git le fait souvent, pas toujours. Parfois il ne sauvegarde pas que tu as résolu un conflit, et te le remontre plus tard. Parfois il mélange tes additions avec celles de tes coauteurs. Parfois il supprime carrément toute une série d'additions parce que tu as voulu inverser juste un merge et envoyer l'inversion à tes coauteurs.
      
      Pijul a été conçu pour n'avoir aucun de ces problèmes.
      
      est-ce qu'il me fournit un historique de ce que j'ai fait?
      
      Git est en effet super fort là-dessus, sauf qu'il en oublie un petit morceau (l'ordre dans lequel tu as travaillé localement après un merge). Pijul s'en rappelle
      
      est-ce qu'il me permet de naviguer dans mes révisions?
      
      Git ne sait naviguer que linéairement. Par exemple, si tu as fusionné une feature A puis une feature B sur ta branche master, avant de faire un commit C, et que les trois sont indépendants, tu ne peux pas simplement et facilement produire une version qui n'a que A et C.
      
      est-ce qu'il me permet de défaire ce que j'ai fait?
      
      Dans Git, pas toujours comme tu voudrais. En local, tu peux toujours. Si tu veux propager l'inverse d'un merge par exemple, c'est moins clair. Certes, si tu travailles tout seul, que tes branches sont relativement simples, tout va marcher, mais c'est dans les cas pourris qu'on a besoin d'un outil solide.
      
      Pijul n'a pas ce problème, tous les patchs ont un unique inverse (et Pijul n'a que des patchs).
      
      est-ce que je peux récupérer des modif's, individuelles ou groupées?
      
      Dans Git, pas vraiment. Tu peux les "récupérer", mais pas les manipuler librement, pour une contrainte purement technique de Git : la raison pour laquelle Git force l'utilisateur à lui présenter un DAG de commits est simplement que les algos de merge qu'il connaît ne savent travailler que comme ça.
      
      Donc si tu veux "récupérer" tes modifs, et les envoyer par exemple par mail, il faut d'abord les convertir en diff, et appliquer le diff dans de bonnes conditions, avant de tenter une fusion qui ne marche pas dans 100% des cas.
      
      Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet.
      
      Ok, je dois reconnaître que si tu as le temps et l'envie de faire ça, je suis un peu jaloux.
      
      En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel
      
      Les pages du manuel de Git, vraiment ? Il en existe même des parodies : https://git-man-page-generator.lokaltog.net/
      
      Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git.
      
      Je reconnais qu'il y a une certaine fierté à maîtriser un outil difficile à utiliser. Je suis moi-même content quand j'arrive à aller au bout d'un git rebase compliqué avec plusieurs co-auteurs, en prenant les changements de tout le monde en minimisant les conflits futurs.
      
      Si tu aimes tes outils, c'est très bien ! C'est important pour bien travailler. Est-ce que ça veut dire que les gens qui ne s'en satisfont pas, ou qui préfèrent passer leur temps sur autre chose, sont nuls ? Je ne pense pas.
      - [^] # Re: Soit j'ai rien compris soit...
        
        Posté par jyes le 26 avril 2019 à 14:28. Évalué à 7.
        
        Merci pour le “git man page generator”, je ne le connaissais pas et je viens de me payer un bonne tranche de rire ! J’aime beaucoup Git et je lis souvent son manuel. Ce site me rassure sur le fait que je ne suis pas le seul à connaître ce petit frisson chaque fois que je découvre une nouvelle sous-commande Git :-)
      - [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 03 mai 2019 à 17:11. Évalué à -2.
        
        Merci pour tes explications, dont je retiendrai en essence ceci:
        
        plein d'utilisateurs de Git pensent que Git travaille avec des diffs, et ne comprennent pas toujours son comportement à cause de ça.
        
        C'est effectivement ce qui répond à la question que je n'ai pas posée de manière explicite. J'en déduis donc que tu possèdes de nombreux retours d'utilisateurs pour en être arrivé à cette conclusion. C'eût été intéressant d'en connaître les proportions, ceci dit. Ce n'est pas une critique, je manifeste juste ma curiosité.
        
        J'aimerais revenir sur certains de tes propos. Tout d'abord:
        
        Ok, on va donc parler vocabulaire : un patch pour nous, c'est un ensemble de changements quelconque. On pourrait aussi dire un "diff".
        
        J'en ai exactement la même compréhension.
        
        Ensuite tu reprends et détailles les différents points que j'ai énumérés. Merci pour cet effort d'avoir détaillé l'expérience des autres.
        
        Cependant je n'ai abordé ces points que pour détailler ce qui comptait pour moi… puisque mon commentaire concluait que je n'ai pas encore eu de raison de passer à autre chose [que Git]. Je ne faisais donc que détailler mon expérience personnelle et en quoi je n'ai pas (encore) eu de raison de changer, puisque Git 1) n'a jamais été pour moi source de la confusion dont tu parles et 2) m'apporte une réponse [au moins] satisfaisante à tous les besoins que j'ai énumérés — ce dernier point était implicite, il n'était pas exprimé, c'est vrai.
        
        Mon commentaire partait d'ailleurs de la confusion entre «commit» et «patch», d'accord? C'est sur cette base, agrémentée de plusieurs autres points, que j'ai argumenté pour arriver à la conclusion.
        
        Ok, je dois reconnaître que si tu as le temps et l'envie de [chercher sur internet], je suis un peu jaloux.
        
        J'ai appris à me démerder et je prends toujours le temps d'apprendre à bien faire les choses dès le début auprès de ceux qui ont l'expérience. J'ai toujours été clair là dessus avec mes employeurs. J'investis ce temps pour mes projets personnels, ce qui me permet d'appliquer au boulot ce que j'apprends.
        
        Je suis conscient d'être probablement un privilégié. Mais à partir du moment où je peux me le permettre…
        
        Pour le reste, j'aimerais aborder des points qui ont tendance à m'irriter un tantinet:
        
        Je te suggère d'imaginer que tes interlocuteurs ne sont pas en train de délirer, et essaient vraiment de proposer un truc autre qu'un changement de vocabulaire.
        
        Qu'est-ce qui te fait croire que j'imagine que «mes interlocuteurs» délirent?
        
        Et par «tes interlocuteurs», c'est de toi que tu parles?
        
        Où exactement et en quoi ai-je réduit ton produit à une simple question de vocabulaire?
        
        Puisque tu abordes ce sujet, dois-je en déduire que tu insinues que je délire?
        
        Ça a le style, l'air et les termes d'une attaque personnelle. Tu peux développer, STP?
        
        Tout message est laissé à l'interprétation de celui qui le reçoit et je ne peux être tenu pour responsable de l'interprétation que quiconque fait de mes propos, surtout sur base du texte seul et sans l’intonation ni l'expression de mon visage. Si tu t'es senti blessé par ce que j'ai raconté, ce n'était pas mon intention; si tel est le cas, j'en suis vraiment navré.
        
        Lorsque j'ai mentionné le mot «vocabulaire», je parlais de la discussion, pas de ton produit. Dans tous les cas, un outil vient avec son vocabulaire et son formalisme, qu'il convient d'apprendre et de maîtriser, que l'outil soit informatique ou non. Tu ne partages pas cette analyse?
        
        Si le vocabulaire et le fonctionnement de Git son mal compris, c'est sans doute là qu'il faut agir — et je ne pars pas du principe que tu ne l'as pas fait. Dans ces cas-là, plusieurs possibilités existent: 1) améliorer la documentation et la compréhension des utilisateurs, 2) améliorer le produit pour qu'il soit mieux compris, 3) changer de produit, 4) en créer un nouveau.
        
        Soit dit en passant, créer un nouveau produit ou en changer parce que le premier n'est pas compris par ses utilisateurs ne résoudra pas ce problème en particulier, n'est-ce pas?
        
        Laisser tomber tes préjugés deux minutes le temps de lire la dépêche aurait suffi à s'en rendre compte.
        
        Peux-tu m'indiquer avec précision de quels préjugés tu parles?
        
        Suggères-tu que ma compréhension de la dépêche est baisée?
        
        Si oui, sur quelles informations précises te bases-tu?
        
        Les pages du manuel de Git, vraiment ?
        
        Je n'ai pas mentionné que ça! Pourquoi t'attarder là-dessus uniquement, alors que j'ai clairement indiqué que je me réfère au manuel ET à ce que je trouve sur internet quand ce dernier ne m'aide pas? À part pour faire un appel au ridicule, je ne vois pas l'intérêt d'un tel commentaire.
        
        Est-ce que ça veut dire que les gens qui ne s'en satisfont pas […] sont nuls ?
        
        J'aurais exprimé ça où, exactement?
        
        Bon, pour terminer sur une note positive:
        
        J'ai l'impression qu'on a les mêmes intérêts […]
        
        Je n'en ai effectivement jamais douté.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 03 mai 2019 à 21:13. Évalué à -1.
        
        Et merde…
        
        Suggères-tu que ma compréhension de la dépêche est b i aisée?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par barmic le 03 mai 2019 à 22:04. Évalué à 7.
        
        Je crois que j'ai compris.
        
        […] les patchs sont plus intuitifs que les commits […]
        
        Il faut comprendre : Un formalisme patch based est plus intuitif que commit based. Et donc oui c'est comparable et non ce n'est pas une question de vocabulaire. Git stock des commits et pijul des patchs.
        
        Affirmer "moi je fais les choses bien et je n'ai pas de problème avec git, donc si on fait les choses bien il n'y a pas de problème avec git" souffre d'un biais qui me paraît évident. Si la dépêche peut être abscons les commentaires ont beaucoup aidé à faire ressortir des cas et à expliquer de diverses façons par plusieurs personnes les impacts du changement de paradigme.
        
        Mais, comme le dis l'auteur, si git te convient c'est parfait.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 04 mai 2019 à 08:55. Évalué à -3. Dernière modification le 04 mai 2019 à 08:58.
        
        Je crois que j'ai compris.
        
        Merci!
        
        Il faut comprendre : Un formalisme patch based est plus intuitif que commit based. Et donc oui c'est comparable et non ce n'est pas une question de vocabulaire. Git stock des commits et pijul des patchs.
        
        Exprimé comme ça, en effet, ça m'éclaire un peu plus sur ce que l'auteur a voulu exprimer concernant ce qui est intuitif ou pas.
        
        Affirmer "moi je fais les choses bien et je n'ai pas de problème avec git, donc si on fait les choses bien il n'y a pas de problème avec git" souffre d'un biais qui me paraît évident.
        
        … sauf que ce n'est pas exactement ce que j'ai dit. Je n'ai pas la prétention de faire les choses bien, j'affirme juste m'inspirer de ceux qui, eux, font bien. Après, je fais de mon mieux et je m'applique.
        
        Ensuite, j'affirme en effet ne pas avoir de problème avec Git et j'explique (en gros) pourquoi. Le reste, «donc si on fait bien les choses bien […]» est une interprétation d'un sous-entendu que je n'ai jamais eu l'intention d'exprimer… et que je n'ai pas exprimé non plus!
        
        Ma litanie est centrée sur une généralisation de la part de l'auteur sur l'inexistence de cette fameuse perception intuitive, ce que je considère excessif (permets-moi un peu de poésie). Et pour réfuter cette affirmation, j'ai tenu le raisonnement suivant, même si je ne l'ai pas détaillé.
        
        La probabilité qu'un développeur lambda rencontre les termes "snapshot", "commit" et "patch" est relativement élevée. On trouve le terme "snapshot" dans le jargon de la virtualisation et de la sauvegarde, les backups. Le terme "commit" se rencontre dans celui des bases de données, notamment. Le "patch" est un terme commun, notamment pour toute personne qui se sert de Linux ayant un jour voulu remonter un bug ou soumettre un correctif (mais pas que).
        
        La probabilité que ces trois termes soient rencontrés par un développeur est relativement élevée. En effet, il n'est pas rare qu'un développeur, dans sa carrière, manipule des bases de données, des machines virtuelles et fasse aussi des backups — c'est à espérer, d'ailleurs! Donc si ces termes sont rencontrés et qu'ils sont bien compris, il ne devrait pas y avoir de confusion.
        
        C'est ça, le raisonnement que j'ai tenu et c'est sur cette seule affirmation (à propos de la perception intuitive) que j'argumentais. Je ne remets en question son produit en aucun cas, bien évidemment.
        
        L'auteur aurait déclaré: «il existe pas mal de monde qui confond patch et commit avec Git, voici pourquoi: …», je n'aurais probablement pas réagi. Peut-être même pas du tout.
        
        Si la dépêche peut être abscons les commentaires ont beaucoup aidé à faire ressortir des cas et à expliquer de diverses façons par plusieurs personnes les impacts du changement de paradigme.
        
        De fait. Je n'ai pas suivi l'affaire depuis mon premier commentaire.
        
        Mais, comme le dis l'auteur, si git te convient c'est parfait.
        
        On est bien d'accord :-) .
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par kantien le 04 mai 2019 à 11:55. Évalué à 6. Dernière modification le 04 mai 2019 à 11:56.
        
        Ensuite, j'affirme en effet ne pas avoir de problème avec Git et j'explique (en gros) pourquoi.
        
        Je suis intrigué par cette remarque, alors je pose un cas pratique n'étant pas un fin connaisseur de git. Prenons un historique de cette forme :
        
        /-- a1 -> A1 -- a2 -> A2 -- a3 -> A3 -\ / \ O ---- b1 -> B1 -- b2 -> B2 -- b3 -> B3 --> AB --> ABC -- ?? -> BC \ / \-- c1 -> C1 -> c2 -> C2 -------------------/
        
        Les lettres majuscules désignent des instantanés du dépôt et les lettres minuscules des patchs. On a trois branches A, B et C avec leurs patchs et commits successifs. On fusionne A et B, puis ensuite on fusionne C. La dernière fusion génère un conflit qui est résolu. On suppose que les changements de la branche A sont totalement indépendants de ceux des autres branches, le conflit venant seulement de la fusion des modifications de B et C. Question : comment, à partir de ABC, annuler les changements apportés par la branche A ? (hint : avec pijul, une seule commande devrait résoudre le problème).
        
        Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème. Il s'agit ici uniquement d'appliquer sur l'état ABC le patch inverse du composé de a1; a2; a3.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 04 mai 2019 à 13:34. Évalué à -4.
        
        Je n'ai pas encore eu à traiter le cas que tu soulèves. Je dois aussi avouer que c'est pas tous les jours que j'élimine des branches ;-). Je ne pourrai donc que répondre de manière intuitive, sur base des commandes que je connais.
        
        Je dirais donc, sur base de ces préliminaires, de supprimer les commits de la branche A. Si je ne m'abuse, supprimer une branche revient à supprimer ses commits. Maintenant, vu que la branche a été fusionnée, je n'ai aucune idée de ce que ça donnerait.
        
        En fait, j'en sais foutre rien :-D. En général, je cherche sur internet lorsque le cas se présente. Et ça ne me dérange pas le moins du monde.
        
        Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème.
        
        Permets-moi de ne pas partager ce point de vue.
        
        Ça m'arrive très souvent de chercher sur internet la syntaxe d'une fonction en C ou en C++.
        
        Ça m'arrive, Ô combien de fois, de chercher sur internet à propos de Python.
        
        Idem pour Git.
        
        Idem pour Linux.
        
        Idem pour bash.
        
        Idem quand je me rends à un endroit que je ne connais pas, je sors mes cartes ou je zieute sur openstreetmap.
        
        Idem quand je prends un médicament pour savoir combien de fois je peux en prendre en une journée (là je lis la notice, œuf corse)
        
        Est-ce que ça veut dire que Python, C, C++, Git, Linux, bash, les médocs, la signalisation routière (ou quoi ou qu'est-ce) ont tous un problème? Ou bien, principe de parcimonie aidant, que je n'ai juste pas une bonne mémoire? Ou bien que je n'utilise pas assez souvent ces ustensiles pour qu'ils me restent en mémoire? Ou que ces outils sont trop complexes pour moi parce qu'ils contiennent plus de variantes ou d'options que ce que j'arrive à retenir? Ou bien parce qu'étant une grosse feignasse, vu que je sais où me documenter, je ne fais pas/plus le moindre effort pour m'en souvenir?
        
        Laquelle de ces explications est la bonne? Peut-être qu'elles le sont toutes?
        
        Tu vois, je ne suis pas aussi catégorique pour juger de ce qu'un outil est bien ou mal fichu. Tout ça relève de l'opinion personnelle dans la plupart des cas. Il y a plus d'une explication pertinente dans pas mal de situations. Le tout est de trouver la plus pertinente. Ça n'est pas toujours facile. Qualifier l'outil est plutôt tentant mais en le faisant, on risque de passer à côté de points bien plus importants, peut-être à côté de l'essentiel.
        
        Git est complexe. Ça, c'est vrai. Trop complexe? C'est bien possible. Mais quand on observe autour de nous, est-ce que "les choses" n'ont pas tendance à se complexifier au point de ne plus pouvoir être maîtrisables par un seul humain? Ne serait-ce pas un signe des temps?
        
        J'en sais rien en fait, je pose juste une question. Enfin, quelque part, si, je me doute. Je me rends compte, notamment, que l'informatique devient de plus en plus complexe et compliquée. Et je pense (c'est mon opinion) que c'est parce que de plus en plus de développeurs n'arrivent pas/plus à apporter des solutions simples à des problèmes simples. Dans beaucoup de cas, j'accepte cette complexité et je fais avec. Dans d'autres cas, je la refuse et je fais tout moi-même. Et parfois, aussi, je baisse les bras et je tourne la page.
        
        Mais bon, je digresse, c'était pas le sujet principal, désolé.
        
        Git a près (plus?) de quatorze ans. Pijul, si j'ai bien lu, a trois ans. Au train où vont les choses, il vaudrait mieux repasser dans une dizaine d'années; on verra bien comment/si l'un et l'autre auront évolués, si notre concept de "simplicité" (et le reste) n'a pas lui non plus évolué…
        
        N.B.: je fais volontairement une différence entre complexe (association d'un grand nombre de choses simples) et compliqué (qu'on a du mal à comprendre, par exemple parce que mal foutu, pas ou peu intuitif, contraire au bon sens…) Donc quelque chose de complexe peut être facile à comprendre, par exemple parce que bien détaillé ou documenté pour chacun de ses sous-ensembles.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 04 mai 2019 à 13:44. Évalué à 2.
        
        J'aime bien ça:
        
        "Goddamn Idiotic Truckload of sh*t": when it breaks
        
        (accentuation par moi)
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par mahikeulbody le 04 mai 2019 à 16:44. Évalué à 3. Dernière modification le 04 mai 2019 à 16:46.
        
        Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème.
        
        La conclusion de cette phrase est dommageable parce que du coup tu digresses (tu le dis d'ailleurs toi-même à la fin). Il aurait été préférable de dire à la place "alors cela vaut peut-être la peine de s'intéresser à un outil qui prétend offrir une approche plus simple et rigoureuse".
        
        En effet, ce n'est pas parce qu'on peut trouver des solutions sur internet aux problèmes posés par un outil, que la recherche d'un outil fonctionnellement équivalent qui ne pose pas ces problèmes n'est pas pertinente (je ne dis pas que c'est le cas de pijul vs. git, j'en sais strictement rien). Parce que sinon pourquoi inventer par exemple de nouveaux langages comme Rust, C faisant le taf malgré ses défauts (STOP, ici c'est juste un exemple par forcément bon, pas le début d'un débat sur C) ?
        
        C'est pas ça qu'on appelle le progrès ?
        
        Et au final on n'a pas la réponse à la question sous-jacente de kantien : aurais-tu trouvé sur internet une solution facile à mettre en œuvre au problème soulevé et combien de temps cela t'aurait pris ?
        
        PS. Comparer le fait d'avoir à chercher sur internet la solution à un problème du type de celui posé par kantien aux exemples de ta liste me paraît assez discutable pour beaucoup d'entre eux.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par kantien le 04 mai 2019 à 19:02. Évalué à 4.
        
        Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème.
        
        La conclusion de cette phrase est dommageable parce que du coup tu digresses (tu le dis d'ailleurs toi-même à la fin). Il aurait été préférable de dire à la place "alors cela vaut peut-être la peine de s'intéresser à un outil qui prétend offrir une approche plus simple et rigoureuse".
        
        Elle est peut être malheureuse, du fait qu'elle a amené une digression de FantastIX, mais je la maintiens. :-P
        
        Je précise que j'ai qualifié ce problème de trivial (il l'est, je donne même la solution juste après) et qu'il fait parti du cœur de métier d'un VCS. Un problème trivial touchant à l'usage même d'un outil devrait être résolu facilement par l'utilisateur, sinon c'est un défaut de conception du logiciel.
        
        Pour l'exemple, il est analogue au cas d'étude du rebasing dans le livre de référence sur git. On a trois branches que l'on rebase :
        
        On peut bien supposer qu'il y a indépendance entre les modifications des parties clients et serveurs. Maintenant supposons, qu'après tous ces rebases on se rende compte que les commits sur le code client ont introduit une faille de sécurité. La correction la plus rapide est de supprimer ces commits en attendant d'analyser le problème et de le résoudre : comment faire avec git vu que les derniers commits présents (ceux du serveur) en dépendent ? On souhaiterait un commande du style git undo client : peut-on l'implémenter simplement autour du cœur de git ? J'en doute, mais je ne demande qu'à être contredit. En tout cas, elle l'est autour de celui de pijul (c'est la solution que j'ai donné manuellement et ce que devrait faire pijull rollback ou pijull unrecord).
        
        Pour bien montrer à quel point le problème est trivial, je vais l'illustrer en prenant des nombres entiers au lieu de fichiers pour les sommets du graphe :
        
        /-- *2 -> 2 -- *3 -> 6 -- *5 -> 30 ----\ / \ 1 ---- *7-> 7 -- *11 -> 77 -- *13 -> 1001 --> 30030 --> 9699690 -- ?? = /30 -> BC = 323323 \ / \-- *17 -> 17 -> *19 -> 323 ---------------------/
        
        Annuler la branche A c'est annuler la multiplication par 30 c'est à dire diviser par 30. Dans les cas des fichiers c'est pareil : il faut inverser le patch global de la branche A, c'est-à-dire prendre l'inverse du composé de a1; a2; a3 puis l'appliquer à l'état ABC.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 05 mai 2019 à 10:30. Évalué à 3. Dernière modification le 05 mai 2019 à 11:43.
        
        comment faire avec git […] ?
        
        Ta question est pertinente et, si c'est à moi que tu poses cette question, je répète, je n'ai pas la solution, n'étant pas non plus un fin connaisseur de Git. Je ne pourrai être certain d'y répondre proprement que lorsque j'aurai du temps à y consacrer.
        
        Ceci dit, on est peut-être en train de chercher midi à quatorze heures. En y réfléchissant quelques secondes de plus, si je te suggères de demander à Git de te renvoyer un patch complet correspondant à la liste des modifications de la branche A (genre git diff ), puis que tu appliques ce patch à "l'envers" (commande patch -r), as-tu ta réponse?
        
        En somme:
        
        git diff a1 a3 > correctif.diff patch -r < correctif.diff # ... ensuite les commits d'usage
        
        Voire mieux:
        
        git diff a3 a1 > correctif.diff patch < correctif.diff # ... ensuite les commits d'usage
        
        Ou encore:
        
        git diff a3 a1 | patch # ... ensuite les commits d'usage
        
        L'avantage est que 1) tu n'as pas à annuler quoi que ce soit (c'est quoi "annuler", d'ailleurs?), 2) il n'est pas nécessaire de ré-écrire l'historique (puisque c'est "mal") si le dépôt public a été modifié et 3) tous les dépôts restent cohérents. Au final, je vois ladite annulation comme une opération de plus.
        
        Et on fait ça avec Git en une seule commande et une seule ligne. À condition que j'aie bien compris ta question, cela va de soi. Je n'ai pas parlé de l'argument "--dry-run" avant d'appliquer un correctif mais prudence oblige, bien entendu.
        
        Est-ce que cette proposition répond à ta question?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 05 mai 2019 à 09:56. Évalué à -1.
        
        PS. Comparer le fait d'avoir à chercher sur internet la solution à un problème du type de celui posé par kantien aux exemples de ta liste me paraît assez discutable pour beaucoup d'entre eux.
        
        Je ne saisis pas. Peux-tu m'expliquer?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par mahikeulbody le 05 mai 2019 à 12:18. Évalué à 6. Dernière modification le 05 mai 2019 à 12:21.
        
        Ta liste donne plutôt des exemples où c'est normal de faire une recherche, soit car on ne peut pas tout connaître - la posologie d'un médicament, soit parce qu'on ne peut pas tout se rappeler - la syntaxe de toutes commandes bash. Il est également normal de faire une recherche quand on est aux limites du scope d'utilisation d'un outil ou dans un cas rare… ou parce qu'on ne connaît pas encore bien l'outil.
        
        kantien te parlait, lui, d'un cas d'utilisation qu'il considère normal pour un CVS (à charge pour toi de le démentir là-dessus s'il y a lieu) et qui ne devrait donc pas entraîner de recherche pour savoir comment le résoudre (rien à voir avec faire une recherche pour retrouver la syntaxe exacte de la commande pijul qui résout son cas).
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 05 mai 2019 à 21:14. Évalué à -1.
        
        Ta liste donne plutôt des exemples où c'est normal de faire une recherche, soit car on ne peut pas tout connaître - la posologie d'un médicament, soit parce qu'on ne peut pas tout se rappeler - la syntaxe de toutes commandes bash. Il est également normal de faire une recherche quand on est aux limites du scope d'utilisation d'un outil ou dans un cas rare… ou parce qu'on ne connaît pas encore bien l'outil.
        
        Ok. Alors dans ce cas, je ne suis pas d'accord sur la conclusion que tu fais de mes propos. J'ai tenu cette liste comme exemples de raisons pour lesquelles on ne doit pas juger un produit sur le simple fait de devoir faire des recherches, ce qui s'appelle une déduction hâtive. Et j'ajouterais aussi: «même pour des cas triviaux». La mémoire, si on ne tient compte que de ça, ben ça flanche. Que tu considères que ces recherches soient "normales" ou non, est sans rapport avec mon propos.
        
        Le cas des médicaments que tu soulèves est un cas particulier du mien et pour lequel je ne partage pas non plus ton point de vue (à savoir que c'est normal de rechercher dans ce cas là). Que mon exemple te paraisse bancal ne contredit en rien qu'il n'est pas bon de faire des déductions hâtives.
        
        kantien te parlait, lui, d'un cas d'utilisation qu'il considère normal pour un CVS […]
        
        Alors ça tombe bien, je lui ai répondu avec un exemple qui tient en une seule commande. J'espère que tu as vu ma réponse. Dis-moi ce que tu en penses.
        
        […] à charge pour toi de le démentir là-dessus s'il y a lieu
        
        Hmmm… tu me donne une charge que je ne suis pas forcé d'accepter. Mais bon, j'arrête de pinailler.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 05 mai 2019 à 14:47. Évalué à 2.
        
        Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème. Il s'agit ici uniquement d'appliquer sur l'état ABC le patch inverse du composé de a1; a2; a3.
        git revert AB^1Afin de bien sélectionner le diff de droite.
        
        Autre question ?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par kantien le 05 mai 2019 à 18:45. Évalué à 2.
        
        Autre question ?
        
        Pas spécialement, c'est la réponse à laquelle je m'attendais (utiliser git revert). Mais il semblerait que ce ne soit pas aussi simple que cela, ensuite, pour la gestion future de la branche : how to revert a faulty merge avec explication en détails, par Linus, des pièges à éviter.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 05 mai 2019 à 23:44. Évalué à 4.
        
        Oui, c'est là qu'on atteint les limites de Git. Essentiellement, l'unique algorithme disponible (contrairement à ce qu'on nous vend) est le 3 way merge et dans certaines situations, déterminer le contributeur de base peut conduire à des cas tordus. Parfois, se baser dessus n'incombe pas le comportement attendu.
        
        Si l'on reprend ton exemple et que -comme dans la vraie vie où l'on a décidé de ne pas livrer un changeset pour une release donnée, car la feature n'était pas prête- l'on l'intègre par la suite, on peut avoir quelques surprises :
        
        /-- a1 -> A1 -- a2 -> A2 -- a3 -> A3 -\ -- a4 -> A4 -------\ / \ \ O ---- b1 -> B1 -- b2 -> B2 -- b3 -> B3 --> AB --> ABC --> BC-- ? \ / \-- c1 -> C1 -> c2 -> C2 -------------------/
        
        Quel est le contributeur de base ici ? A3 ? ABC ?
        Il y a quelques chances que le futur merge considère que la suppression des commits A(1,2,3)= BC soit retenue dans le merge automatique et qu'on ne retrouve pas ces commits que l'on voudrait intégrer.
        
        Un "excellent/magique" VCS permettrait de lever un conflit ou tout au moins de préciser explicitement cette intégration.
        J'attends toujours l'exemple concret qui montrerait que Pijul s'en sortirait mieux. J'attends aussi qu'on me démontre que la gymnastique intellectuelle que l'on doit appliquer afin de comprendre les cas où l'outil ne se comporterait pas comme on serait en droit de l'attendre, vaudrait de s'y investir.
        
        En attendant, la bonne pratique, que tu "insinues" alambiquée est de ne pas intégrer les features non complètes et plutôt de merger depuis (ou rebaser sur) le trunk régulièrement pour se tenir à jour. On appelle ça: le feature branching.
        
        Au pire, on constate les dégâts rapidment (vive la CI) et l'on reconstruit une branche bien propre à base de rebase interactifs.
        
        Dans "la vraie vie", on aurait plutôt quelque chose de ce genre:
        
        /-- a1 -> A1 -- a2 -> A2 -- a3 -> A3 --- a4 -> A4 --\ / / \ \ O ---- b1 -> B1 -- b2 -> B2 -- b3 ---> B3 ---> BC --------->ABC \ / \-- c1 -> C1 -> c2 -> C2 -------------------/
        
        Bref, "dans la vraie vie" ton cas n'existe quasiment JA-MAIS
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 06 mai 2019 à 09:11. Évalué à 6.
        
        Un "excellent/magique" VCS permettrait de lever un conflit ou tout au moins de préciser explicitement cette intégration.
        J'attends toujours l'exemple concret qui montrerait que Pijul s'en sortirait mieux.
        
        Ok, je te suggère d'essayer Pijul sur ce cas, tu verras qu'il fait le bon truc. Je ne vais pas te donner les exemples avec des diffs (mais tu ne me les donne pas non plus pour Git).
        
        Le modèle de Pijul ici est que tu as trois ensembles de patchs:
        
        A: { a1, A1, a2, A2, a3, A3, a4, A4 }
        
        B: { b1, B1, b2, B2, b3, B3 }
        
        C: { c1, C1, c2, C2 }
        
        Tu veux prendre des patchs dans A et les ajouter dans B:
        
        pijul pull --from-branch A --to-branch B a1 A1 a2 A2 a3 A3
        
        Tu veux prendre des patchs dans C et les ajouter dans B:
        
        pijul pull --from-branch C --to-branch B -a
        
        Maintenant tu as trois ensembles:
        
        A: { a1, A1, a2, A2, a3, A3, a4, A4 }
        
        B1: { a1, A1, a2, A2, a3, A3, b1, B1, b2, B2, b3, B3, c1, C1, c2, C2 }
        
        C: { c1, C1, c2, C2 }
        
        Je les ai ordonnés par ordre alphabétique, parce que dans Pijul deux patchs produits sur des branches différentes peuvent être appliqués dans n'importe quel ordre sans changer le résultat (même s'il y a des conflits).
        
        Si tu veux virer un ou plusieurs patchs (par exemple on veut virer b3, B3 et C2), tu peux faire :
        
        pijul unrecord b3 B3 C2
        
        J'attends aussi qu'on me démontre que la gymnastique intellectuelle que l'on doit appliquer afin de comprendre les cas où l'outil ne se comporterait pas comme on serait en droit de l'attendre, vaudrait de s'y investir.
        
        Ma réponse est que le modèle de Pijul avec des ensembles est ultra simple. Il y a des preuves mathématiques que ça se comporte toujours "comme on s'y attend", c'est-à-dire que tous les conflits sont détectés, qu'ils sont résolubles par un seul patch, que les patchs sont associatifs ("pull AB, puis pull C" fait la même chose que "pull A, puis pull BC"), et que les patchs produits indépendamment commutent toujours.
        
        C'est nous qui avons fait la gymnastique intellectuelle pour écrire cet outil, pas besoin de la refaire quand on l'utilise.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 06 mai 2019 à 14:16. Évalué à 2. Dernière modification le 06 mai 2019 à 14:16.
        
        Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.
        
        Si j'essaie de comprendre ce que que tu exprimes:
        Avec une vision "ensembliste" des patchs, on peut ré-agencer comme on le souhaite. La souplesse et la consistance seraient au rendez-vous car tout ceci est "mathématiquement" prouvé. Soit!
        
        Le fait de ne pas ré-appliquer les commits (cherry-pick) est un plus car il conserve l'identité des patchs. Ok. (J'imagine que tu réarranges le graphe des patches en modifiant les arcs).
        
        Pourtant, tu ne nies pas que seuls les patchs produits en // commutent. J'ai vraiment du mal à comprendre.
        
        Par ailleurs, une petite critique au passage sur la documentation (Je sais que c'est encore en version alpha):
        D'une manière générale, elle mélange les concepts et l'interface.
        En tant qu'utilisateur, le format du repo m'importe peu (https://pijul.org/manual/format.html) . Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.
        pijul pull --from-branch A --to-branch B a1 A1 a2 A2 a3 A3Là, tu inclues les ids de commits. Tu voulais peut-être écrire:
        pijul pull --from-branch A --to-branch B a1 a2 a3Nous sommes en local dans le même repo.
        La doc de "pull" indique que la commande concerne la synchronisation avec des repo distants
        https://pijul.org/manual/reference/pull.html. Le pull prend en charge la fusion aussi ?
        
        D'autres choses m'interrogent (on peut mettre ça sur le compte de la maturité du projet , j'imagine).
        
        Quid de la séparation entre la synchro (fetch) et la mise à jour du workspace (merge)? Parfois c'est utile de ne pas recourir à un "git pull" et procéder en 2 temps.
        
        Comment tagguer une version ? Je lis dans la FAQ que ce n'est pas implémenté. Et surtout que les perfs risquent de s'en ressentir (O(n) vs O(1) pour git). De douloureux souvenirs s'éveillent en moi, ancien utilisateur de Clearcase et de SVN.
        
        Qu'en est-il du .gitignore ? Je me vois mal être obligé de préciser moi-même explicitement tous les fichiers à versionner. Est-ce que l'option --recursive du add en tient compte ?
        
        Je ne vais pas te donner les exemples avec des diffs (mais tu ne me les donne pas non plus pour Git).
        
        Ce n'est pas moi qui essaie de mettre en avant les atouts de mon projet. Un peu de pédagogie serait bienvenue. Les dépêches défilent et il n'est toujours question que de "théorie". Même si je comprends que tu préfères t'investir sur le projet, le temps d'écrire un tutoriel aurait largement été compensé par celui que tu passes à répondre ici ou sur reddit.
        
        Je précise que ceci n'est pas une attaque.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 07 mai 2019 à 00:42. Évalué à 5.
        
        Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.
        
        Certes. On peut aussi écrire tout ce qu'on veut en Brainfuck, c'est Turing-complet.
        
        La question est, à quel coût ? Si on peut faire la même chose bien plus simplement, de manière plus déterministe, plus rigoureuse et plus concise, je ne comprends vraiment pas l'argument pour s'en priver.
        
        (J'imagine que tu réarranges le graphe des patches en modifiant les arcs).
        
        Il n'y a pas de DAG de commits dans Pijul, juste des ensembles de patchs.
        
        C'est pourtant écrit dans la doc existante des dizaines de fois, je l'ai redit dans mon commentaire plus haut, c'est partout dans toute notre communication, et dans les tutoriels contribués par d'autres. Je doute que des tutoriels supplémentaires changent quoi que ce soit.
        
        En tant qu'utilisateur, le format du repo m'importe peu
        
        Oui, moi aussi je m'en fous, mais on nous l'a demandé. Apparemment tout le monde n'a pas les mêmes intérêts.
        
        Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.
        
        Je ne suis pas sûr de comprendre. Pourquoi tu ne peux pas simplement faire pijul add, pijul status ou pijul log pour voir ça ?
        
        Si tu juges utile d'avoir ça dans la doc, tu es le bienvenue pour faire un patch du manuel:
        
        https://nest.pijul.com/pijul_org/manual
        
        Quid de la séparation entre la synchro (fetch) et la mise à jour du workspace (merge)? Parfois c'est utile de ne pas recourir à un "git pull" et procéder en 2 temps.
        
        C'est utile dans Git (je le fais souvent) parce que Git peut parfois déconner complètement quand il merge, et on veut pouvoir examiner le patch avant parce qu'on sait qu'on aura du mal à revenir en arrière. Dans Pijul, ce n'est pas implémenté, mais je doute franchement de l'utilité, parce que (1) Pijul a un algo de merge correct et (2) on peut toujours revenir en arrière, dans 100% des cas.
        
        Comment tagguer une version ? Je lis dans la FAQ que ce n'est pas implémenté. Et surtout que les perfs risquent de s'en ressentir (O(n) vs O(1) pour git). De douloureux souvenirs s'éveillent en moi, ancien utilisateur de Clearcase et de SVN.
        
        pijul tag existe pourtant, c'est dans la doc.
        
        Dans la FAQ, il y a un paragraphe sur la navigation dans les versions. C'est plus subtile dans Pijul que dans Git, parce que Git est séquentiel, mais ce n'est pas non plus la mort dans Pijul. C'est même un peu plus flexible, puisqu'on peut composer une version avec seulement certains patchs.
        
        Pour l'instant, on s'en sort à coups d'unrecord (la commande qui enlève des patchs). Pour le futur, on réfléchit à une interface plus efficace, qui tirerait partie de la puissance des ensembles de patchs, tout en restant au moins aussi simple que git checkout.
        
        Qu'en est-il du .gitignore ? Je me vois mal être obligé de préciser moi-même explicitement tous les fichiers à versionner. Est-ce que l'option --recursive du add en tient compte ?
        
        Pour --recursive, c'est pourtant dans la doc : https://pijul.org/manual/reference/add.html
        
        Pour .gitignore, ce n'est pas dans la doc, mais c'est dans ce tutoriel : https://nest.pijul.com/tae/pijul-for-git-users
        
        Ce n'est pas moi qui essaie de mettre en avant les atouts de mon projet. Un peu de pédagogie serait bienvenue. Les dépêches défilent et il n'est toujours question que de "théorie".
        
        Je veux bien répondre à des questions sur des exemples "concrets", encore faut-il me donner ces exemples. Pourquoi les branches et commits dessinés en ascii art constituent des exemples concrets, et ma réponse non ?
        
        Même si je comprends que tu préfères t'investir sur le projet, le temps d'écrire un tutoriel aurait largement été compensé par celui que tu passes à répondre ici ou sur reddit.
        
        Je te suggère de cliquer sur l'onglet "documentation" de https://pijul.org, il conduit là : https://pijul.org/manual/
        
        Il y a déjà de la doc, à laquelle on peut contribuer, poser des questions, etc. C'est un projet open source.
        
        Si l'objectif est de comprendre, lire la doc existante et poser des questions peut aider. Si l'objectif est de se convaincre et de convaincre les autres que Git est mieux, lire la doc de Pijul ne sert pas forcément.
        
        Je ne doute d'ailleurs pas du tout que Git soit mieux dans plein de cas, et pour plein de gens.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 11:51. Évalué à 1.
        
        Il n'y a pas de DAG de commits dans Pijul, juste des ensembles de patchs.
        C'est pourtant écrit dans la doc existante des dizaines de fois, je l'ai redit dans mon commentaire plus haut, c'est partout dans toute notre communication, et dans les tutoriels contribués par d'autres. Je doute que des tutoriels supplémentaires changent quoi que ce soit.
        
        Je n'ai pas parlé de commit mais de graphe de patchs. Et il me semble bien que c'est le cas non ?
        
        Je cite:
        
        Pijul manipule un graphe de lignes. Chaque sommet est une ligne, les arêtes ont un statut. Un patch est un ensemble:
        - de nouveaux sommets et arêtes
        - et de changements de statut d'arêtes.
        
        https://linuxfr.org/news/pijul-controle-de-version-et-theorie-des-patchs-version-0-12#comment-1768959
        
        aka graggles:
        https://jneem.github.io/merging/
        
        Pourquoi les branches et commits dessinés en ascii art constituent des exemples concrets, et ma réponse non ?
        
        Après je suis désolé de t'importuner, mais pour moi un exemple concret, ça serait plus un tutoriel qui compare des actions git et pijul sur un repo avec un vrai fichier exemple et permettrait de montrer comment leur comportement diffère.
        
        Bref, exactement ce que Jehan a développé.
        
        Et sans vouloir te vexer, question tutoriels, Google ne m'a pas beaucoup aidé en ce sens.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 12:10. Évalué à 5.
        
        Je n'ai pas parlé de commit mais de graphe de patchs. Et il me semble bien que c'est le cas non ?
        
        Certes, mais ça ne veut pas dire qu'on réarrange quoi que ce soit. Au contraire, on a une structure de données où on sait prouver que l'ordre n'importe pas, et donc que deux dépôts avec le même ensemble de patchs, même dans des ordres différents, sont équivalents sans qu'on n'ait besoin de "réarranger".
        
        Après je suis désolé de t'importuner, mais pour moi un exemple concret, ça serait plus un tutoriel qui compare des actions git et pijul sur un repo avec un vrai fichier exemple et permettrait de montrer comment leur comportement diffère.
        
        Bref, exactement ce que Jehan a développé.
        
        Et sans vouloir te vexer, question tutoriels, Google ne m'a pas beaucoup aidé en ce sens.
        
        Je ne suis pas du tout vexé ! Je sais bien que la doc n'est pas aussi étoffée que je voudrais. Ceci dit, les quelques exemples concrets qui ont été donnés ici (notamment le cas où Git mélange les lignes n'importe comment, mais pas seulement) ont été soit ignorés, soit commentés d'un "ok, Pijul le fait gratuitement, mais avec Git je peux faire la même chose en tapant cinq commandes, après avoir passé une heure à lire la doc et à régler des trucs à la main".
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 12:35. Évalué à 0.
        
        Certes, mais ça ne veut pas dire qu'on réarrange quoi que ce soit. Au contraire, on a une structure de données où on sait prouver que l'ordre n'importe pas, et donc que deux dépôts avec le même ensemble de patchs, même dans des ordres différents, sont équivalents sans qu'on n'ait besoin de "réarranger".
        
        Ok, cette base de donnée qui s'appuie sur un b-tree peut-être.
        Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?
        
        ont été soit ignorés, soit commentés d'un "ok, Pijul le fait gratuitement, mais avec Git je peux faire la même chose en tapant cinq commandes, après avoir passé une heure à lire la doc et à régler des trucs à la main".
        
        Ce que tu ne saisis pas je crois c'est que les exemples se sont cantonnés à du ASCII Art.
        Et comprends aussi que nombre d'entre nous sont à l'aise avec cet outil pour un usage quotidien.
        
        J'ai essayé de te donner un début d'exemple avec un fichier concret un peu comme ce qui est décrit ici pour Darcs:
        https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory
        
        Tu m'as immédiatement asséné que seuls les patchs // commutent.
        C'est toi qui est le mieux à même d'illustrer les exemples différenciant, pour convaincre.
        Nous sommes tous désireux d'adopter un outil qui s'appuie sur un modèle théorique solide, à condition qu'il démontre qu'il répond à nos besoins et qu'il nous apporte du mieux.
        
        Au passage, dans cette doc sur Darcs ce sont les patchs séquentiels qui commutent, il semblerait. Ca plus les graphes de lignes: Votre modèle semble bien différent, même s'il s'en inspire.
        Ca n'aide pas non plus à la compréhension.
        
        Je crois que c'est moi qui vais m'y coller sur ce tuto parce que visiblement c'est un dialogue de sourds
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 13:05. Évalué à 1.
        
        Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?
        
        Je ne sais pas à quoi tu fais référence. J'ai essayé de ne faire que des commentaires objectifs et rigoureux, je suis désolé si tu as mal pris un truc.
        
        J'ai essayé de te donner un début d'exemple avec un fichier concret un peu comme ce qui est décrit ici pour Darcs:
        
        Malheureusement, tout ce qui est décrit dans ce tutoriel sur Darcs est faisable avec Git, du temps, des pages de manuel, et plein de bonne volonté pour ignorer les cas pourris (les cas "à la marge", pour reprendre un de tes commentaires).
        
        Je ne vois pas pourquoi les arguments que j'ai lus ici pour ignorer ces exemples seront différents.
        
        Je crois que c'est moi qui vais m'y coller sur ce tuto parce que visiblement c'est un dialogue de sourds
        
        J'ai déjà posté ce lien ici-même, par exemple : https://nest.pijul.com/tae/pijul-for-git-users
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 13:33. Évalué à 2.
        
        les cas "à la marge", pour reprendre un de tes commentaires).
        
        Désole de t'avoir piqué, mais ce cas est vraiment marginal en effet. Je ne l'ai rencontré que sur 2 projets durant toute ma "longue" carrière dans une boîte de 500 devs et pourtant le support Git m'incombe.
        
        En revanche, si comme tu l'évoques les rebase qui s'effectuent une fois sur 2 avec un conflit sont évités. Là ça devient intéressant. Et c'est ça qu'on trouve un peu "magique"
        
        J'ai déjà posté ce lien ici-même, par exemple : https://nest.pijul.com/tae/pijul-for-git-users
        
        C'est un début, mais c'est sur la partie branche qu'on souhaiterait plus de matière.
        
        Allez, ne disperse pas ton énergie.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 14:57. Évalué à 1.
        
        C'est un début, mais c'est sur la partie branche qu'on souhaiterait plus de matière.
        
        Il n'y a pas besoin de branches dans Pijul, les patchs font le boulot. Elles sont implémentées pour faciliter la recomposition de versions, mais ce n'est pas le truc central.
        
        Malheureusement, il n'y a pas grand chose à dire de plus dessus : une branche dans Pijul, c'est un ensemble de patchs, et c'est tout. On peut faire des unions d'ensembles, des intersections, déplacer des éléments entre les ensembles, mais il n'y a rien d'autre à comprendre.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 15:45. Évalué à 6.
        
        Tu as intégré ce nouveau paradigme et tu as confiance en lui car il s'appuie sur une théorie mathématique dans laquelle tu baignes.
        C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.
        
        Pour beaucoup, le modèle conceptuel derrière Mercurial (des sous graphes connexes en quelque sorte) interpellait les afficionados de Git.
        
        Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).
        Mais même si c'est mal nommé le terme de "branche" est couramment admis.
        En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
        Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
        Dans les mal nommés "branching patterns", on parle de branchement par release.
        
        Avec un DVCS on peut imaginer 2 moyens pour maintenir des variantes:
        - S'appuyer sur des forks (un par variante) auquel cas la notion de branche perd tout sens
        - Faire cohabiter les 2 variantes dans un même repo. Il faut donc mettre en place un mécanisme pour les matérialiser.
        
        Le modèle de base de Hg correspond au premier et perturbe les utilisateurs git (alors que git peut aussi le supporter en conservant une branche unique).
        
        Donc oui ce n'est pas "absolument" indispensable mais confortable tout de même et fort heureusement Pijul le supporte.
        
        Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
        C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 23:14. Évalué à 6.
        
        C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.
        
        Je comprends totalement, et je réalise que certains de mes commentaires ont pu paraître abrupts. Ce n'était pas mon intention.
        
        Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).
        
        C'est exactement ça !
        
        Mais même si c'est mal nommé le terme de "branche" est couramment admis.
        En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
        Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
        Dans les mal nommés "branching patterns", on parle de branchement par release.
        
        Je ne connais absolument rien à ces patterns, mais je suis super intéressé. Si tu peux nous expliquer comment renommer nos concepts sur https://discourse.pijul.org, ce sera avec plaisir. On a déjà parlé de remplacer les noms "push" et "pull", de renommer les "patchs" en "changes" ou "contributions", et des gens se sont déjà plaints du nom "branche".
        
        Bref, la terminologie est toute cassée, et n'aide pas à comprendre pour l'utilisateur qui vient de Git. D'autant plus qu'on a essayé de conserver les noms de commandes quand c'était possible, dans l'espoir d'être moins déroutant (l'idée est qu'un utilisateur basique de Git soit déjà un utilisateur presque complet de Pijul, il ne lui reste plus qu'à apprendre unrecord et rollback).
        
        Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
        C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.
        
        Avec plaisir ! N'hésite pas à nous rejoindre sur le discourse, ou même à envoyer des patchs sur le manuel (https://nest.pijul.com/pijul_org/manual)
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par Sytoka Modon (site web personnel) le 10 mai 2019 à 20:22. Évalué à 10.
        
        Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?
        
        Moi je trouve que depuis le début il répond très calmement et du mieux qu'il peut. Bravo à lui. Par contre, moi, en tant que regard extérieur à cette conversation, je te trouve sur l'agressivité tout le temps et limite méprisant.
        
        Voila, c'était une remarque que je voulais faire à toi mais il y a en d'autres qui sont un peu sur la même longueur d'onde que toi sur ce post.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 20:33. Évalué à 4.
        
        Reçu, Capitaine Modon!
        
        Je vais essayer de mettre de l'eau dans mon vin.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par Sytoka Modon (site web personnel) le 10 mai 2019 à 20:56. Évalué à 2.
        
        Merci ;-)
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 23:23. Évalué à 4.
        
        Moi je trouve que depuis le début il répond très calmement et du mieux qu'il peut. Bravo à lui.
        
        Du mieux que je peux, certes, mais c'est vrai que je dis des gros mots mathématiques, et que j'ai parfois mélangé les niveaux d'explications en peu vite, en alternant sans trop de transition entre rigueur mathématique et pratique quotidienne.
        
        C'est vrai que dans la pratique quotidienne, Git marche plutôt bien. Je tombe régulièrement sur des cas pourris quand je sors un peu des clous (par exemple quand j'essaie de recomposer une version de NixOS déployable en production, sans tenir compte de mes dernières contributions à leur GitHub), mais sur des cas plus classiques ça passe.
        
        Par contre, au niveau rigueur mathématique, on peut considérer Git comme "tout cassé", parce qu'il n'y a pas de preuve mathématique.
        
        L'un des problèmes pour expliquer Pijul, c'est qu'il n'a pas ces cas pourris dans la pratique, et que ça vient de la théorie, donc il y a un moment ou on doit sauter de l'un à l'autre.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par barmic le 06 mai 2019 à 06:58. Évalué à 4.
        
        Le solution de pijul retire les commits de l'historique ?
        
        Si oui ça n'est pas une bonne bonne option pour tous les projets. Chaque projet définit ce qu'il veux avoir comme information dans son historique. La notion de "cette liste de changement a posé tel problème" peut en faire parti et donc être intéressante.
        
        De plus ca modifierai l'historique d'une branche partagée, ce qui pose d'autres problèmes.
        
        Enfin dans pijul, (ABC -> x1 -> X) - A peu poser des problèmes vu que x1 peu dépendre de A.
        
        Avoir de petites branches et les supprimer une fois mergé ne me paraît pas être une contrainte chercher à nettoyer son historique de tout les problèmes rencontrés n'est pas forcément une bonne idée non plus.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 06 mai 2019 à 09:15. Évalué à 5. Dernière modification le 06 mai 2019 à 09:15.
        
        On peut laisser les commits dans l'historique : pijul rollback produit un patch qui en inverse un autre, les deux restent dans l'historique. pijul unrecord enlève des patchs de l'historique, mais ils sont toujours sur le système de fichiers.
        
        Avoir de petites branches et les supprimer une fois mergé ne me paraît pas être une contrainte
        
        Encore une fois, ça dépend à quel point tes bugs sont compliqués, de combien de personnes sont sur le projet, de la proximité de la deadline, du temps que tu veux consacrer à faire des rebase bien propres (pour satisfaire une contrainte technique de Git), etc.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par barmic le 06 mai 2019 à 11:21. Évalué à 2.
        
        Quel va être l'apport de pijul rollback face à un git revert ?
        
        Petite dans le sens qui ne fait qu'une seule chose. Ça ne dépend pas de ta deadline ou autre au contraire. Tu fais de une chose et tu l'intègre s'il y a un problème tu crée une nouvelle branche, je ne vois pas la complexité que ça apporte.
        
        Pour ce qui est des problèmes de résolution de conflits (lors des rebase par exemple), effectivement git va moins t'aider que pijul, mais tu va avoir des problèmes tout de même. Pijul n'est pas magique, 10 dev qui touchent le même fichier en parallèle, c'est pas un problème de gestion de version.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par kantien le 06 mai 2019 à 13:05. Évalué à 2.
        
        Quel va être l'apport de pijul rollback face à un git revert ?
        
        Déjà, on n'aura pas besoin de revert le revert ou faire du rebase dans certaines situations afin de ne pas mettre le 3-way merge dans la panade (mais ça c'est une propriété générale de la fusion sous pijul).
        
        En revanche je me pose la même question que toi : est-ce que pijul rollback se contente d'inverser les patchs passer en arguments ou est-ce qu'il inverse aussi ceux qui en dépendent ? Autrement dit, prend-t-il en compte la relation de dépendance entre patch ?
        
        Si j'ai cet historique :
        
        O -> p -> q -> r -> A
        
        que r dépend de p mais que q commute avec eux, lorsque je fais pijull rollback p, est-ce que r est aussi inversé ? C'est là pour moi un avantage important de pijull face aux autres : ne pas avoir à résoudre manuellement un problème qui peut être fait automatiquement (et qui pourrait s'avérer difficile à résoudre à la main, n'ayant pas nécessairement bien en tête les relations de dépendances entre patchs). C'est-à-dire, pijull rollback p applique p' ou r'; p' (le ' dénote l'inverse) ?
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 07 mai 2019 à 00:49. Évalué à 5. Dernière modification le 07 mai 2019 à 00:49.
        
        Quel va être l'apport de pijul rollback face à un git revert ?
        
        pijul rollback marche pour 100% des patchs, même ceux qui créent ou résolvent des conflit, même sur des merges. Ce n'est pas le cas de git revert.
        
        Ça ne dépend pas de ta deadline ou autre au contraire. Tu fais de une chose et tu l'intègre s'il y a un problème tu crée une nouvelle branche, je ne vois pas la complexité que ça apporte.
        
        Il faut créer une nouvelle branche, la rebaser, l'entretenir, la fusionner. Bref, il faut réfléchir au contrôle de versions au lieu de réfléchir au vrai travail qu'on versionne.
        
        Pour des projets pas trop compliqués, ou très bien planifiés, où on peut se permettre de prendre le temps pour penser aux rebases, aux créations de branches et aux merges, ça peut marcher.
        
        Pour les projets sur lesquels je travaille, ça me fait perdre du temps.
        
        Pijul n'est pas magique, 10 dev qui touchent le même fichier en parallèle, c'est pas un problème de gestion de version.
        
        En effet, mais:
        - dans Git c'est déjà la catastrophe avec deux.
        - Pijul peut gérer les dix, puisque tu peux toujours revenir en arrière.
        
        Cette remarque est-elle vraiment de bonne foi ?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par barmic le 07 mai 2019 à 06:26. Évalué à 3.
        
        Cette remarque est-elle vraiment de bonne foi ?
        
        C'est exactement la question que je me posais au sujet de ta réponse. Je pense que l'on ne s'est pas compris. Je vais essayer d'être un peu plus clair.
        
        Je suis d'accord avec toi que git n'aide pas du tout dans ces cas là. On doit même pouvoir trouver des cas pathologiques où il amplifie le problème.
        
        Mais je personnellement les cas où j'ai vu ce genre de modifications parallèles de même fichiers, soit était triviales et pijul, git ou svn ne poserait pas de gros problème, soit était signe de gros problèmes de design et demandais à redévelopper une partie d'une fonctionnalité. Et cela sans que ce soit la faute du gestionnaire de version. Même sans conflit, si tu as une refacto de l'existant et un ajout de fonctionnalités, pijul le pourra pas automatiquement appliquer la refacto sur le nouveau code (pour un exemple simple à décrire).
        
        S'organiser ce n'est pas qu'une question de vcs, c'est une question de qualité. Tu as déjà plusieurs fois sorti la parabole du projet sous pression, de mon humble avis le vcs n'est pas leur seul soucis (et j'aurais tendance à dire que le vcs est plus un symptôme).
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 08 mai 2019 à 01:09. Évalué à 4.
        
        C'est exactement la question que je me posais au sujet de ta réponse.
        
        Celui qui dit c'est celui qui y est ? Aucune de mes réponses aux commentaires ici n'a été de mauvaise foi, ou n'a utilisé des exemples caricaturaux. Par contre, le coup des dix développeurs qui touchent la même fonction, il faut avouer que ça n'apporte pas grand chose au débat, on est tous d'accord qu'aucun outil ne va faire de miracle.
        
        Je pense que la dichotomie entre les deux cas que tu décris montre bien en quoi Git transforme ses utilisateurs :
        
        soit était triviales et pijul, git ou svn ne poserait pas de gros problème,
        
        Avec Git, tout ce qui n'est pas à une personne et une branche n'est pas trivial. En gros, dès qu'il y a un merge sur le même fichier (même si les deux branches ont touché des morceaux très éloignés du fichier), il peut se passer n'importe quoi.
        
        soit était signe de gros problèmes de design et demandais à redévelopper une partie d'une fonctionnalité
        
        Là, on n'est carrément pas d'accord. Bien sûr, n'importe quoi de non-trivial sous Git demande de passer des heures à satisfaire les contraintes techniques de l'outil, de revoir la communication, de mieux former les collaborateurs du projet aux bonnes pratiques, de rendre le workflow plus rigoureux…
        
        Parfois c'est aussi le cas dans d'autres systèmes de contrôle de version, bien sûr. Sauf que quand on travaille ensemble, la plupart des cas ne tombent dans aucune de tes deux catégories.
        
        Dans mon expérience de programmeur et de co-auteur de textes en général, il y a plein de petits cas assez simples, mais pas complètement triviaux non plus. Bien sûr, on peut passer du temps à rebaser, à corriger les merges qui ont mélangé les lignes, à organiser ses branches en workflows. Mais avec un outil plus rigoureux, on pourrait aussi utiliser tout ce temps-là pour travailler sur le projet au lieu de satisfaire Git.
        
        Exemple, dans l'écriture d'un projet comme Pijul, où les co-auteurs se font confiance et travaillent assez indépendamment sans se synchroniser outre mesure, il arrive qu'on ait des problèmes. Pourtant, vu qu'on travaille tous sur plein de sous-projets à la fois (parce qu'il y a beaucoup à faire, et qu'on n'est pas beaucoup), aucun de nous n'a envie d'adopter une structure rigide de branches, des merges temporaires pour vérifier que deux features passent bien ensemble, etc.
        
        Un truc particulièrement difficile dans Pijul est que si on change la sortie d'un algo, il faut adapter tous les algos qui dépendait de cette sortie. Ça fait des gros patchs, mais avec Pijul on s'en sort très bien, je suis certain que Git nous aurait déjà donné du fil à retordre (j'utilise Git souvent).
        
        Autre exemple, écrire un article en LaTeX. On travaille ensemble sur un peu tout, en s'échangeant parfois les parties à rédiger, à relire et à corriger. Parfois on fait des conneries, par exemple on résout mal un conflit. Ça peut arriver parce qu'on a choisi de travailler avec un co-auteur pour ses compétences en maths ou en littérature, pas parce qu'il maîtrise tel ou tel VCS. Il faut pouvoir virer le patch foireux, ou au moins en calculer l'inverse, même si ce patch résout un conflit ou "merge" des choses.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par FantastIX le 09 mai 2019 à 08:49. Évalué à -1.
        
        Je ne comprends pas cette obsession autour de git revert et de l'idée d'annuler des patch. J'ai répondu avec une commande du style:
        git diff X Y | patch
        que personne n'a commenté, non content de ça et qui s'est faite moinsser sans la moindre explication. J'aimerais comprendre, c'est tout.
        
        Ré-écrire l'historique, quelle qu'en soit la raison, dans un projet quel qu'il soit est en effet une très mauvaise idée et le commentaire de barmic explique pourquoi. Alors, je repose ma question, autrement: est-ce qu'il y a quelque chose de dérangeant dans ma suggestion? Et, si oui, pourquoi?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par kantien le 09 mai 2019 à 11:25. Évalué à 7.
        
        Je ne comprends pas cette obsession autour de git revert et de l'idée d'annuler des patch.
        
        Ce n'est pas une obsession, c'est juste la continuité de la discussion autour de problème que j'ai posé. Pour ce qui est de l'idéé d'annuler un patch, c'est une des fonctionnalités que tu attends d'un VCS :
        
        est-ce qu'il me permet de défaire ce que j'ai fait?
        
        La solution avec git, sans réécrire l'historique, c'est d'utiliser git revert. Personnellement, c'est la réponse à laquelle je m'attendais (même si la tienne fait la même chose, c'est moins idiomatique) et c'est ce qu'a proposé El Titi.
        
        Néanmoins, le problème que j'ai posé était un piège tendu de ma part. ;-) En utilisant git revert (ou ta commande), vous prenez le risque de mettre 3-way merge dans la panade plus tard. Voilà comment Linus préconise d'annuler un merge foireux : un exemple typique du besoin de lire une bonne pratique pour effectuer une action de base sans avoir de problème.
        
        Ce défaut est propre au VCS qui utilise 3-way merge comme algorithme de fusion, ce qui n'est pas le cas de pijul. D'ailleurs, pour quelqu'un qui aime la précision sémantique des mots utilisés, c'est bien là le problème de tous ces VCS : ils n'ont pas de définition claire de ce qu'est une fusion, un comble pour une opération si fondamentale dans un tel outil ! :-) À ce sujet, tu pourras lire mon commentaire qui traite de la question qu'est-ce qu'une fusion ?
        
        Et au-delà de ce problème (qui reste central dans tous ces VCS), il y a celui de déterminer l'indépendance entre patchs. Dans mon problème, je précisais bien que les modifications des branches B et C étaient indépendantes de celles de la branche A. C'est à cette seule condition (l'indépendance) qu'il suffit de revert le merge entre A et B pour défaire ce qui a été fait. Si l'on souhaite définir formellement (et donc clairement) ce que signifie ce mot indépendance, cela consiste à dire que les patchs commutent. Voilà pourquoi pmeunier insiste tant sur cette notion de commutation de patchs. En conséquence, s'il n'y avait pas commutation il faudrait aussi défaire d'autres patchs que ceux de la branche A (ce que ne saura pas faire git revert ni ta commande : il faudrait résoudre le problème à la main). Par exemple si, après la fusion de la branche C, j'ajoute un patch p qui dépend du travail de la branche A alors il sera aussi défait automatiquement par pijull rollback AB mais pas par git revert (ni ta commande).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 09 mai 2019 à 21:16. Évalué à 1.
        
        Oui sauf qu'avec toutes ces tergiversations, on n'a toujours pas vu un cas où la "commutation de patchs aurait ce comportement attendu.
        
        Surtout, ce que tu as décrit (et que j'ai complété, c'est plutôt moi qui l'ai tendu le piège) intervient très rarement dans un process GCL digne de ce nom (à base de PR par exemple)
        
        Pour l'instant, donc à part un cas purement théorique, je ne vois pas l'intérêt de changer d'outil si les avantages se limitent à ça.
        
        Lorsqu'on vous demande un seul exemple concret, vous ressassez la théorie, l'auteur me renvoie aux "tutoriaux" et sans vouloir vous vexer, c'est carrément la disette:
        https://www.google.fr/search?q=pijul+tutorial&oq=pijul+tutorial
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par kantien le 09 mai 2019 à 21:33. Évalué à 5. Dernière modification le 09 mai 2019 à 21:35.
        
        Surtout, ce que tu as décrit (et que j'ai complété, c'est plutôt moi qui l'ai tendu le piège) intervient très rarement dans un process GCL digne de ce nom (à base de PR par exemple)
        
        Si tu parlais en français, ou dans une langue que tout un chacun peut comprendre, cela faciliterait grandement les choses. Je veux parler de ces termes comme « process GCL digne de ce nom » qui chez toi on peut être un sens, mais chez moi c'est : qu'est-ce qu'il dit ? Pour le reste des tes commentaires, cela reste dans la même zone : le fait que le système puisse planter dans des cas tordus, qui ne sont même pas rejeter par Linus (toi tu les rejettes pour cacher la poussière sous le tapis), ne te déranges pas : grand bien t'en fasse, mais je comprends mieux pourquoi il y a tant de bugs dans les logiciels existants; la rigueur intellectuelle ne semble pas être une priorité pour certains.
        
        Honnêtement, si tu penses réellement m'avoir tendu un piège, de quelque forme qu'il soit, il faudra que tu me montres où il se trouve. La seule chose que tu as fait c'est nier un problème que même Linus ne nie pas et auquel il propose une solution pour contourner les limites de git.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 09 mai 2019 à 23:21. Évalué à 1.
        
        Pardon, c'est un terme assez usuel dans l'industrie logicielle: https://fr.wikipedia.org/wiki/Gestion_de_configuration_logicielle
        qui fait même l'objet de normes:
        https://blog.ansi.org/2017/05/configuration-management-iso-100072017/
        https://www.boutique.afnor.org/standard/ieee-828/configuration-management-in-systems-and-software-engineering-note-approved-2012-02-06-ieee/article/800191/us044653
        
        la rigueur intellectuelle ne semble pas être une priorité pour certains.
        
        En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.
        
        C'est d'ailleurs une des forces de Git. Je me souviens de tous ces innombrables VCS (systèmes de contrôles de version :) qui se targuaient de gérer mieux que quiconque le"rename tracking" en le rendant explicite et qui se sont ramassés sur les cas tordus.
        Avant que tu ne m'objectes de parler chinois, je te renvoie ici (cherche le terme Merge file renames):
        https://en.wikipedia.org/wiki/Comparison_of_version-control_software
        
        En gros, comment se débrouille un merge entre 2 branches lorsque le fichier est renommé ?
        Il faut détecter que le fichier a été renommé pour appliquer le merge plutôt que de créer un nouveau fichier.
        
        Certains VCS conservent la trace des renommages explicites.
        
        Git a fait un choix différent. Il utilise une de ces "heuristiques" tant décriées par certains.
        Il compare simplement le contenu du fichier et considère qu'il a été renommé si le contenu est semblable.
        Oh mon dieu, quelle horreur! Ca marche pour 95% des cas mais ce n'est pas mathématiquement prouvé.
        Tu peux même ajuster le taux de recouvrement pour tes besoins (find-renames: https://git-scm.com/docs/git-merge)
        
        Seulement voilà, les autres VCS partisans de la stratégie explicite s'y sont cassés les dents parce que dans les cas tordus, ça foire. Au hasard (SVN, Mercurial, Bazar, Monotone, …)
        Il y a même eu un wiki pour répertorier tous ça. Il est down maintenant mais un petit gars a essayé de le sauver.
        https://github.com/tonyg/revctrl.org
        
        Honnêtement, si tu penses réellement m'avoir tendu un piège, de quelque forme qu'il soit, il faudra que tu me montres où il se trouve.
        
        Je me corrige:
        
        (et que j'ai complété, c'est plutôt moi qui ME LE SUIS tendu le piège)
        
        C'est moi qui ai développé ton graphe pour montrer le cas qui pose pb, il me semble.
        
        Maintenant, si tu acceptes d'utiliser un ton à peine moins condescendant, on pourrait peut-être reprendre le fil de la conversation et tu pourrais peut-être répondre à la question au lieu de tourner autour du pot:
        
        on n'a toujours pas vu un cas où la commutation de patchs aurait ce comportement attendu.
        
        Si on prend aussi le temps de répondre, ce n'est pas forcément pour "démonter" Pijul. Bien au contraire. Et je serai le 1er à m'enthousiasmer pour le challenger qui enterrera Git (Plusieurs pourraient en témoigner ici)
        
        Tiens pour le fun:
        https://linuxfr.org/users/minimock/journaux/git-a-fete-ses-10-ans-hier
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 09:18. Évalué à 5.
        
        En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.
        
        Je voudrais juste rappeler qu'on discute d'un vrai outil ici, pas d'une hypothétique théorie.
        
        Pijul a 20000 lignes de code. Il dépend de deux projets des mêmes auteurs :
        
        Thrussh, une implémentation complète de SSH en Rust, asynchrone, qui suit les états du protocole pour éviter les blagues. 10000 lignes de code.
        
        Sanakirja, un dictionnaire clef-valeur sur disque, transactionnel, avec une opération "clone" sans copie. 4000 lignes de code.
        
        L'un des auteurs (Florent Becker) a aussi été l'un des plus gros contributeurs au projet Darcs.
        
        De plus, autant Florent que moi-même sommes de gros utilisateurs de Git, de Darcs, et parfois de SVN.
        Nous avons donc eu l'occasion de comparer très pragmatiquement ces outils avec Pijul.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par Matthieu Moy (site web personnel) le 10 mai 2019 à 13:19. Évalué à 6.
        
        Oui, mais dans beaucoup de tes messages, tu tentes d'expliquer en gros que Git ne marche pas dès qu'on sort d'un hello-world. Je cite : « Avec Git, tout ce qui n'est pas à une personne et une branche n'est pas trivial. En gros, dès qu'il y a un merge sur le même fichier […], il peut se passer n'importe quoi. », « Git mélange les lignes n'importe comment », …
        
        Git est utilisé pour une bonne partie des plus gros projets logiciels de la planète. Pijul a 20000 lignes de codes, c'est environ 100 fois moins que le nombre de fichiers du dépôt Git de Windows par exemple (à ma connaissance le plus gros qui existe aujourd'hui). Alors oui, Git a des défauts, mais « il peut se passer n'importe quoi », « n'importe comment », …, ce n'est pas le vocabulaire que j'utiliserais pour le décrire. Et c'est dommage, parce que ces phrases à mon avis déplacées te font perdre en crédibilité. En lisant ces messages, j'ai un peu l'impression de lire le discours des Linuxiens qui n'ont pas touché à Windows depuis 20 ans et qui essayent d'argumenter que Windows, c'est de la merde, ça plante tout le temps et il faut reformater le disque et réinstaller toutes les semaines. Honnêtement, si tu trouves que Git fait n'importe quoi au point où tu l'écris dans tes messages, c'est que le problème ne vient pas que de l'outil. Que Pijul ait des choses à apporter, ça m'a l'air assez clair, mais expliquer ça à des gens en commençant par leur expliquer que l'outil qu'ils utilisent avec succès au quotidien ne peut pas marcher et qu'il fait tout le temps n'importe quoi n'est à mon avis pas le bon premier pas pour convaincre.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par barmic le 10 mai 2019 à 13:29. Évalué à 2.
        
        Je suis entièrement d'accord avec toi. Je pense que c'est parce qu'il passe beaucoup de temps à travailler sur les cas problématiques et fini par ne voir que ça.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 15:18. Évalué à 4.
        
        Ou peut-être parce qu'il travaille sur des projets différent des tiens, parce qu'il veut un outil qui marche dans 100% des cas, et ne veut pas avoir à se plier à une discipline stricte quand ce n'est pas nécessaire.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 15:06. Évalué à 4.
        
        C'est un résumé complètement tronqué de mon propos, qui se concentre sur un vocabulaire assez banal quand on essaie de décrire des algorithmes mathématiquement.
        
        Au fil de mes commentaires, j'ai aussi décrit explicitement des cas où Git se trompe complètement, j'ai répété plusieurs fois que je l'utilisais régulièrement. J'ai parlé des workflows et des bonnes pratiques qui permettent de rester dans les clous pour des raisons purement techniques.
        
        Et comme je l'ai dit plein de fois ici, je suis au courant (ayant un petit peu bossé sur le sujet) que Git marche souvent, dans plein de cas et pour plein de gens.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 15:16. Évalué à 6.
        
        D'autre part, les commentaires qui ignorent toutes les difficultés de Git me semblent de mauvaise foi : il y a quand même une commande git rerere, ça ne s'invente pas !
        
        J'ai aussi répété au moins deux fois que c'était chouette que des gens aiment bien Git et se sentent productifs avec.
        
        J'ai répété aussi que ce n'était pas mon cas, peut-être parce que ma façon de travailler (en général sur plein de trucs à la fois, souvent avec de petites équipes sur des sujets peu planifiables) ne se prête pas à la rigueur de Git.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 19:18. Évalué à 3.
        
        il y a quand même une commande git rerere, ça ne s'invente pas !
        
        1 point pour toi. Je commence à me laisser séduire.
        
        Par contre, vous avez conscience que Git est hégémonique aujourd'hui ? Quasiment toutes les forges s'appuient dessus. Un écosystème phénoménal s'est construit autour pour pallier certaines de ses erreurs de jeunesse, …
        Darcs a eu ses chances et est passé aux oubliettes.
        
        Qu'est-ce qui ferait qu'aujourd'hui Pijul réussirait mieux et ne répéterait pas les mêmes erreurs que son aïeul malgré ses atouts ?
        
        J'ai bien ma petite idée mais les tiennes m'intéressent.
        
        De mon coté, je vois déjà le fait que l'implémentation était basée sur un langage assez abrupt et confidentiel. Rust est plus populaire, il me semble.
        
        L'autre point qui ne manquait jamais d'apparaître dans les trolls de l'âge d'or des VCS, c'était quand même les perfs assez déplorables de Darcs.
        Le modèle de données a évolué et les algos aussi de ce que je comprends.
        Mais il reste ce point évoqué dans votre FAQ: le “exponential merge problem”. Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
        Ceci ne remet-il pas en question tout l'édifice ?
        Pourrais-tu développer un peu ?
        
        Question subsidiaire: Un point important pour son adhesion est l'interopérabilité.
        J'ai cru voir qu'il y avait des scripts d'import depuis Git mais je crois que ce qui rassurerait les early adopters serait plutôt un genre de pont qui permettrait de se synchroniser avec un repo git tout en jouant avec Pijul en local (un peu comme git-svn).
        Etant donné les différences d'approche, j'ai conscience que ça limiterait l'expression du potentiel de Pijul (pas de bijection: 2 commits git de même contenu ne matchant pas un même patch) mais penses-tu de la faisabilité ?
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 10 mai 2019 à 23:40. Évalué à 5.
        
        Par contre, vous avez conscience que Git est hégémonique aujourd'hui ? Quasiment toutes les forges s'appuient dessus. Un écosystème phénoménal s'est construit autour pour pallier certaines de ses erreurs de jeunesse, …
        
        C'est vrai, et on en avait totalement conscience au moment de démarrer. Mais:
        
        Au début, comme Florent et moi travaillons en général sur des modèles de calcul asynchrone (plutôt sur de la vraie théorie), le défi nous a motivés.
        
        Ensuite, on a vu à la première démo (même toute ridicule) que c'était un sujet controversé, que l'hégémonie de Git ne faisait pas que des heureux, que des gens souffraient en l'utilisant.
        
        Et on a parlé avec des gens qui n'utiliseront jamais Git, même s'ils ont besoin d'un VCS, parce qu'ils ont besoin d'un outil aussi puissant que Git, mais beaucoup plus facile à utiliser (ce n'est pas pour du code).
        
        L'autre point qui ne manquait jamais d'apparaître dans les trolls de l'âge d'or des VCS, c'était quand même les perfs assez déplorables de Darcs.
        
        C'est ça qui a tué Darcs. Le principal utilisateur était GHC (le compilateur Haskell), avec un dépot énorme, et le merge exponentiel, l'incapacité à gérer des gros fichiers ou des gros patchs ont poussé GHC à changer, même s'ils ont essayé de le soutenir pendant longtemps. À l'époque où Haskell était encore confidentiel, Darcs a été le seul projet open source écrit avec, en dehors du compilateur.
        
        Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
        
        Pas du tout. Notre merge est toujours en temps O(log H), où H est le nombre de lignes écrites depuis le début du dépot, il n'y a pas d'heuristique, il est complètement déterministe, donc il n'y a pas d'optimum local, puisqu'il n'y a rien à minimiser (contrairement à diff3).
        
        Ceci ne remet-il pas en question tout l'édifice ?
        
        Donc non !
        
        Pourrais-tu développer un peu ?
        
        En fait c'est ultra simple. Pijul modélise un fichier comme un graphe de lignes. Faire un patch, c'est ajouter des sommets et des arêtes, ou changer les étiquettes des arêtes. Fusionner deux patchs, c'est faire l'union de tous ces changements, c'est-à-dire l'union de deux ensembles de sommets. C'est aussi simple que ça.
        
        Les trucs difficiles sont :
        - Une astuce pour ne pas regarder les lignes qui ont été supprimées, sinon la complexité devient O(H).
        - Des algos non-triviaux pour modéliser la résolution de conflits comme ajout de sommets.
        - Un algo pour "désappliquer" un patch (la commande pijul unrecord).
        
        Le seul point non-optimal est l'algo de diff, parce que le problème est NP-complet s'il y a un conflit, et on utilise un algo d'approximation.
        
        Etant donné les différences d'approche, j'ai conscience que ça limiterait l'expression du potentiel de Pijul (pas de bijection: 2 commits git de même contenu ne matchant pas un même patch) mais penses-tu de la faisabilité ?
        
        C'est totalement faisable, et sans doute pas très dur. C'est clairement la prochaine étapie, mais ce n'est pas encore écrit. J'ai connaissance de plusieurs tentatives, et j'étais jusqu'à maintenant assez occupé sur le reste (montrer que Pijul pouvait marcher, par exemple !).
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 11 mai 2019 à 15:09. Évalué à 2.
        
        Merci pour cette réponse étayée.
        
        D'un point de vue algorithmique, tout se présente pour le mieux.
        Mais malgré tout quelques inquiétudes que je ne semble pas être seul à partager.
        Pour accomplir tout ça de manière déterministe, il semble qu'il faille redonder énormément d'informations.
        
        Sur votre discourse, le dernier bench est plutôt encourageant au niveau des perfs:
        https://discourse.pijul.org/t/bad-performance/134/11
        
        Sincères félicitations, mais tout de même, 230 Mo de stockage pour 17 Mo de lignes de code ça fait quand même peur.
        Je n'ose pas imaginer un dépôt plus conséquent en terme de bande passante au niveau du clone.
        
        Dans ma boîte, on a plusieurs projets de + de 1 Go (avec des binaires, certes) et Bitbucket est carrément à la ramasse avec un clone qui part en timeout.
        Mais bon un dépôt de l'ordre de 200 Mo, c'est quand même assez fréquent.
        
        J'espère sincèrement qu'il y a encore matière à optimiser, au moins pour le transport.
        
        En tout cas, c'est déjà un sacré boulot d'accompli.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 11 mai 2019 à 15:43. Évalué à 2.
        
        Désolé tu as déjà répondu:
        
        I’d say the main thing to expect before 1.0 could be one last format change to reduce the disk space usage, and handle large (possibly binary) files more easily. The patch format shouldn’t change, so there will be almost no disruption.
        
        https://discourse.pijul.org/t/pijul-0-12-released/313
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par _seb_ le 10 mai 2019 à 23:50. Évalué à 1. Dernière modification le 10 mai 2019 à 23:50.
        
        Par contre, vous avez conscience que Git est hégémonique aujourd'hui ?
        Combien de logiciels étaient "hégémoniques" autrefois et sont devenus obsolètes aujourd'hui ? Ces faux arguments ne doivent pas être un frein à l'innovation, à mon humble avis.
        
        Qu'est-ce qui ferait qu'aujourd'hui Pijul réussirait mieux et ne répéterait pas les mêmes erreurs que son aïeul malgré ses atouts ?
        Parce que nous apprenons généralement de nos erreurs. Les longues discussions ici même entre ce que peuvent ou ne peuvent pas faire Git et Pijul en sont de bons exemples.
        
        Pijul est développé en Rust, un langage de plus en plus populaire. Et ce que je constate avec la communauté Rust, c'est une volonté de bien faire les choses tout en conservant du pragmatisme.
        J'espère que le projet Pijul est influencé par cette façon de faire.
        
        Je crois qu'il ne manque par de travail sur le projet Pijul pour celui ou celle qui souhaite s'y intéresser et s'investir. Par exemples:
        - lire la documentation et faire remonter toutes les remarques
        - tester Pijul et faire remonter toutes les remarques
        - rédiger une dépêche sur linuxfr ou sur un blog pour faire remonter toutes les remarques
        - rédiger, corriger, améliorer, traduire la documentation
        - coder des évolutions, des corrections, des tests unitaires
        - proposer/contribuer à des projets annexes (interfaces UI web ou non, git2Pijul, svn2Pijul, xxx2Pijul)
        - proposer/répondre à un sondage du projet (à la "Rust survey") pour connaître les attentes de la communauté sur le projet
        - ou tout simplement utiliser Pijul pour ses propres besoins et remercier les auteurs du projet
        
        @pmeunier si je dis des bêtises ou s'il manque des points, n'hésites pas à en faire part.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 11 mai 2019 à 01:36. Évalué à 4.
        
        Merci Seb pour ta contribution enthousiaste.
        
        J'ai envie de répondre: Why not ?
        
        Je peux déjà commencer par le dernier point:
        
        Ou tout simplement utiliser Pijul pour ses propres besoins et remercier les auteurs du projet
        
        Merci aux auteurs de porter le flambeau du Git NG et en guise d'encouragement, je ne peux que citer son papa:
        
        Does Git last forever, or do you foresee another revision control system in another 10 years? Will you be the one to write it?
        
        Torvalds: I'm not going to be the one writing it, no. And maybe we'll see something new in ten years, but I guarantee that it will be pretty "git-like." It's not like git got everything right, but it got all the really basic issues right in a way that no other SCM had ever done before.
        
        No false modesty ;)
        
        Source
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 13 mai 2019 à 12:37. Évalué à 1.
        
        En lisant ces messages, j'ai un peu l'impression de lire le discours des Linuxiens qui n'ont pas touché à Windows depuis 20 ans et qui essayent d'argumenter que Windows, c'est de la merde, ça plante tout le temps et il faut reformater le disque et réinstaller toutes les semaines
        
        Pardon, j'avais loupé cette accusation particulièrement grossière. Je ne vois ni le rapport avec le sujet, ni en quoi ça fait avancer la discussion. Je ne sais pas où j'aurais dit un truc pareil.
        
        C'est con, parce que si tu voulais une comparaison entre un truc d'ingénierie "qui-marche-somme-toute-pas-mal" et un truc qui vient d'une théorie propre, il y avait d'autres exemples largement plus à propos :
        
        Tu pouvais parler par exemple de OCaml, Haskell, Erlang, des curiosités académiques, que les programmeurs Java prenent de haut, parce que "Java/C++ ça marche bien quand même", "c'est toi le problème, si tu définis pas tes classes proprement". Bien sûr, ça n'aurait pas trop alimenté ta hargne, parce qu'aujourd'hui ces langages sont mainstream. Mais on ne peut pas non plus être tout le temps hargneux.
        
        En moins consensuel (parce que plus récent), tu aurais pu tenter un troll sur NixOS (issu d'une thèse) contre Debian ou RedHat (les standards qui marchent-bien-quand-même). Tu aurais pu dire que ce n'est quand même pas la mort de lire des pages de manuel Debian pendant des heures pour pouvoir faire un brouillon de package pour "GNU Hello", à perfectionner pour éviter qu'il casse à la première mise à jour.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par Diagonale de Cantor (site web personnel) le 13 mai 2019 à 12:50. Évalué à 2.
        
        Tu pouvais parler par exemple de OCaml, Haskell, Erlang, des curiosités académiques
        
        Pour info, Erlang n'est pas du tout académique et provient de l'industrie des télécoms. En pratique et malgré son originalité on sent rapidement des motivations très pragmatiques loin du culte de la pureté théorique.
        
        Ce n'est pas une critique, car je trouve ce langage absolument géniale, mais pour le coup c'est un mauvais exemple au contraire de ocaml et d'haskell.
        
        PS : à propos de NixOS quand est-ce que la version 12 de Pijul y sera présente ? Pour l'instant je n'a réussi qu'à installer la version 11.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 13 mai 2019 à 13:26. Évalué à 3.
        
        Pour info, Erlang n'est pas du tout académique et provient de l'industrie des télécoms.
        
        Bien sûr, je parlais de "curiosité académique" dans le sens "théorie qui ne sert à rien". Et ni OCaml, ni Haskell, ni NixOS, ni Pijul n'ont comme motivation la pureté théorique, bien au contraire.
        
        La version 12 de Pijul devrait arriver bientôt. Elle est pour l'instant un peu compliquée à compiler, il faut bricoler un peu Carnix avant d'y arriver, et trouver une solution pérenne à l'accumulation de vieux crates dans nixpkgs.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par Matthieu Moy (site web personnel) le 13 mai 2019 à 15:41. Évalué à 4.
        
        Ce n'est pas une accusation, c'est l'impression que certains de tes messages me donnent (j'ai fait attention à écrire « j'ai un peu l'impression de » et pas « tu es du même niveau que » …). Tu avais l'air surpris de voir que certains de tes interlocuteurs trouvaient tes messages agressifs, et j'ai tenté de te donner une explication de mon point de vue. Mais entre temps tu t'es expliqué dans ce commentaire qui me paraît bien plus constructif.
        
        Je ne vois ni le rapport avec le sujet
        
        Le rapport est ce que j'écrivais plus loin :
        
        « […] expliquer ça à des gens en commençant par leur expliquer que l'outil qu'ils utilisent avec succès au quotidien ne peut pas marcher et qu'il fait tout le temps n'importe quoi n'est à mon avis pas le bon premier pas pour convaincre. »
        
        Les linuxiens bornés auxquels je fais allusion (mais je n'ai écrit nulle part que tu en faisais partie, hein !) font en général bien rire les Windowiens qui connaissent un minimum leur système. Tu as donné de très bons arguments en faveur de Pijul (qu'il faut clairement que je regarde plus en détails), mais je trouve que les messages où tu laisses entendre, ou bien écris explicitement que n'importe quoi de non-trivial sous Git est infaisable ne les mettent pas en valeur, et mettent potentiellement tes lecteurs sur la défensive.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 14 mai 2019 à 15:06. Évalué à 4.
        
        Les linuxiens bornés auxquels je fais allusion (mais je n'ai écrit nulle part que tu en faisais partie, hein !) font en général bien rire les Windowiens qui connaissent un minimum leur système.
        
        C'est ce que j'avais compris (et j'avais noté la précaution de t'en tenir à une insinuation).
        
        Mais pour avoir parlé avec des gens qui connaissent très bien Git et l'utilisent beaucoup, le fait qu'on travaille à une alternative basé sur une théorie propre ne les fait pas rire.
        
        n'importe quoi de non-trivial sous Git est infaisable
        
        C'est encore une extrapolation de ce que j'ai écrit. Elle va moins loin que la précédente (la comparaison avec Windows et Linux), mais elle n'est pas rigoureuse pour autant.
        
        J'ai écrit que dès qu'on bossait avec plusieurs branches ou plusieurs coauteurs, c'était non-trivial. "Non-trivial", ça ne veut pas dire inutilisable ou que je ne le comprends pas (contrairement à l'insinuation "le problème ne vient pas de l'outil"), ça veut juste dire qu'il y a besoin de réfléchir et de faire un truc (par exemple git rebase) pour que ça marche (et d'ailleurs, parfois c'est vraiment dur, même pour des experts).
        
        Ceci dit, si ces extrapolations (qui ne sont pas de moi) sont ce que tu as retenu de mon discours, ton impression que je suis un fanatique en croisade contre Git est justifiée. Sauf que ce n'est pas ce que j'ai écrit…
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par ZeroHeure le 14 mai 2019 à 12:49. Évalué à 4.
        
        En lisant ces messages, j'ai un peu l'impression de lire le discours des Linuxiens qui n'ont pas touché à Windows depuis 20 ans et qui essayent d'argumenter que Windows, c'est de la merde, ça plante tout le temps et il faut reformater le disque et réinstaller toutes les semaines
        
        Pardon, j'avais loupé cette accusation particulièrement grossière. Je ne vois ni le rapport avec le sujet, ni en quoi ça fait avancer la discussion. Je ne sais pas où j'aurais dit un truc pareil.
        
        Comme l'a écrit Mathieu Moy ça n'était pas accusateur.
        Je comprends que tu sois énervé par la discussion et les arguties sans fin, mais en tant que modérateur habitué à l'agacement ressenti sur linuxfr, je t'invite à mettre un peu d'eau dans ton vin : la plupart de tes interlocuteurs sont très connus ici pour être de bonne foi et aussi des dévelopeurs très expérimentés avec Git (Jehan par exemple est un des piliers de Gimp).
        
        Une bonne partie des questions et des reproches vient de la dépêche dont tu n'es pas entièrement responsable (c'est Nyco et moi qui l'avons "triturée"). On aurait du la renvoyer en rédaction plutôt que la compléter maladroitement nous-mêmes. J'en suis désolé. Cela étant, il faut faire avec et tu peux retravailler ta documentation et tes exemples comme ça t'a été suggéré, c'est à dire beaucoup plus concrètement. Car si tu es visiblement à l'aise avec les abstractions, ce n'est pas le cas des lecteurs. De même, on sent que les défauts de Git font partie des motivations de Pijul, mais au fond ça n'est pas le plus important pour motiver les gens à utiliser Pijul. Il vaut beaucoup mieux synthétiser en quelques phrases le bénéfice sur le flux de travail (plus besoin de brancher à tout va par exemple) et lister dans un second temps les avantages sur Git (merge, rapidité, …). Enfin, puisque la liste des défauts de Git fait bondir un public habitué à l'adorer et focalise la discussion, il vaut mieux la mettre en toute fin, assortie d'une comparaison commande Git / commande Pijul.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par pmeunier le 14 mai 2019 à 14:43. Évalué à 3.
        
        la plupart de tes interlocuteurs sont très connus ici pour être de bonne foi et aussi des dévelopeurs très expérimentés avec Git.
        
        Je m'en suis rendu compte, et j'ai apprécié la qualité de cette discussion en général. J'ai aussi appris pas mal de trucs sur la façon de documenter Pijul (clairement notre prochain défi !).
        
        J'ai aussi approuvé votre "triturage" de la dépêche avant la publication, donc je ne suis pas sûr que tu puisses être désolé de quoi que ce soit.
        
        [^] # Re: Soit j'ai rien compris soit...
        
        Posté par El Titi le 10 mai 2019 à 00:09. Évalué à 4.
        
        La seule chose que tu as fait c'est nier un problème que même Linus ne nie pas et auquel il propose une solution pour contourner les limites de git
        
        Je me cite:
        
        Oui, c'est là qu'on atteint les limites de Git. Essentiellement, l'unique algorithme disponible (contrairement à ce qu'on nous vend) est le 3 way merge et dans certaines situations, déterminer le contributeur de base peut conduire à des cas tordus. Parfois, se baser dessus n'incombe pas le comportement attendu.
        
        En revanche ile est clair que les méthodes de projets modernes (agiles) atténuent grandement les désagréments liés à ces problématiques de fusions.
        Que ce soit le Continuous Delivery, Scrum ou autres. Elles s'appuient sur la création de branches par fonctionnalité (feature branches) et l'intégration via des pull requests, ce qui limite leur durée de vie dans le temps.
        
        Certains protagonistes vont même plus loin en prônant le "trunk dev" (une branche unique) pour encourager l'intégration continue (au sens propre), principe fondateur de l'agilité.
        https://martinfowler.com/bliki/FeatureBranch.html
        Ils proposent d'autres techniques pour aborder les developpement // comme
        https://www.martinfowler.com/articles/feature-toggles.html
        https://martinfowler.com/bliki/BranchByAbstraction.html
        
        Hormis les considérations GCL (pardon, de versionning) elles apportent d'autres avantages (A/B testing, …).
        
        Bref, dans la vraie vie, ces scénarios que vous décrivez n'existent qu'à la marge et ne justifient pas un changement d'outil.
        
        Mais je ne doute pas que Pijul a d'autres arguments et nous démontrera ses vertus. Il a pour lui de beaux arguments (Rust, une UI épurée, la jeunesse, une théorie que j'aimerais voir concrètement appliquée, …)
        
        A suivre
# ... quelques problèmes (notamment sur l'espace disque): ne pas utiliser une BD ! URL + fichiers

Posté par Legrego le 25 avril 2019 à 10:33. Évalué à 2.

Je pense que vous avez manqué un point central du succès de git: contrairement aux autres VCS modernes, il n'utilise pas une BD !

le .git/ ressemble à un site web statique: des fichiers textes contenant des liens (URL) vers d'autres fichiers textes ou des fichiers contenant le code du commit. Ils sont tous compressés avec Zip et c'est (presque) tout (Je raccourcis un peu: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)

Ce modèle de données ultra simple permet de facilement ajouter des nouveaux outils (Les nombreux gui diverses et variés, duplicity …) ou commandes par dessus (git lsf, git annex, git module, git subtree… ), les backups ne stockent pas un fichier unique au format obscur, …

Mais vous pouvez encore changer ce point, car le reste à l'air vraiment cool :-)
- [^] # Re: ... quelques problèmes (notamment sur l'espace disque): ne pas utiliser une BD ! URL + fichiers
  
  Posté par pmeunier le 25 avril 2019 à 10:49. Évalué à 9.
  
  Je pense que vous avez manqué un point central du succès de git: contrairement aux autres VCS modernes, il n'utilise pas une BD !
  
  Avec tout mon respect, je pense que c'est plutôt toi qui a dû louper un truc. Les auteurs de Pijul comprennent en fait assez bien Git, au moins assez pour en voir les limites.
  
  Dans Pijul, il y a aussi plein de petits fichiers compressés avec Gz: des patchs, qui sont facilement exploitables pour faire des GUIs si on veut (nest.pijul.com est un exemple). Le problème, c'est que si on n'a que des patchs, l'expérience de Darcs montre que c'est difficile de faire un système efficace.
  
  La "base de données" de Pijul est simplement une structure de données pour rendre le truc efficace. Il serait un peu triste de s'interdire d'utiliser des structures de données autres que des listes chaînées, surtout quand (comme les auteurs de Pijul) on se croit chercheurs en informatique.
  
  D'autre part, la "base de données" n'est pas une obscure représentation tirée du chapeau, elle est totalement exploitable avec une bibliothèque existante, écrite en Rust (et donc interfaçable facilement avec C/C++, Python, Java, …).
  - [^] # Re: ... quelques problèmes (notamment sur l'espace disque): ne pas utiliser une BD ! URL + fichiers
    
    Posté par Guillaume Knispel le 26 avril 2019 à 00:28. Évalué à 3.
    
    Hm comme souvent y a probablement des avantages et des inconvénients des deux côtés…
    
    Par exemple git utilise des hard links pour avoir des clones locaux légers. Alors certes si on a pas ça on peut envisager un modèle plus worktree-style, mais avec ça aussi il y a des avantages et des inconvénients.
    
    On peut encore noter la possibilité de gérer des dépots gigantesques "simplement" en virtualisant le FS (enfin c'était le plus gros du boulot)—MS a fait ça pour mettre tout le code source de Windows sous Git.
    
    Enfin je connais pas les internals de Git mais je vois pas trop pourquoi on pourrait pas construire des structures de données plus complexes que des listes chaînées en partant d'un tel modèle ni en quoi ça disqualifirait pour être un "chercheur en informatique" (au contraire…)
    
    Ceci étant dit, je ne déteste pas le fait d'utiliser une DB, mais simplement à lire votre échange, hm, c'est pas en jouant au tennis à coup de qui a "loupé un truc" que chacun va être incité à améliorer sereinement ses connaissances et sa compréhension des compromis, avantages et inconvénients de chaque solution.
    - [^] # Re: ... quelques problèmes (notamment sur l'espace disque): ne pas utiliser une BD ! URL + fichiers
      
      Posté par pmeunier le 26 avril 2019 à 11:28. Évalué à 5.
      
      Par exemple git utilise des hard links pour avoir des clones locaux légers. Alors certes si on a pas ça on peut envisager un modèle plus worktree-style, mais avec ça aussi il y a des avantages et des inconvénients.
      
      Le commentaire initial n'était clairement pas très informé, et supposait des trucs faux sur Pijul.
      
      La structure de données que Pijul utilise pour représenter un dépôt est assez subtile, et ne pourrait sans doute pas être implémentée avec le seul système de fichiers, pour des questions de transactionalité.
      
      en quoi ça disqualifirait pour être un "chercheur en informatique" (au contraire…)
      
      C'était justement ce que je voulais dire : parfois, on doit utiliser des trucs plus subtiles, et pas seulement parce qu'on a "loupé un truc". Git arrive à être transactionnel (c'est-à-dire qu'il n'est jamais dans un état où un commit est à moitié fait) parce que sa structure de données de commits est un DAG de blobs.
      
      Pijul a besoin d'une structure un peu plus subtile pour arriver à ses fins, parce qu'il fait des trucs que Git ne sait pas faire.
      
      Ceci étant dit, je ne déteste pas le fait d'utiliser une DB
      
      Je ne suis pas sûr de savoir ce que ça veut dire, il n'y a pas de "bases de donńees" dans Pijul, juste une structure de données qui a la complexité optimale pour les opérations qu'on veut faire dessus.
# Et pour les fichiers binaires ou du moins autres que texte?

Posté par abriotde (site web personnel, Mastodon) le 25 avril 2019 à 14:22. Évalué à 2. Dernière modification le 25 avril 2019 à 14:23.

La démarche de Pijul est intéressante (Je verrais bien cet algo mis dans Git un jour).
Néanmoins, ce que j'aimerais c'est un DVCS qui gère assez simplement les fichiers binaires ou du moins les fichiers "zip" comme les documents LibreOffice. Certes en ce qui concerne LibreOffice, il existe une certaine gestion de l'historique interne, mais j'aimerais un outils plus général. Je sais qu'il existe des outils Open-Source de diff de binaire, alors un système de gestion de version générique doit pouvoir exister non?

PS : Git est mauvais sur ce point.

Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
- [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
  
  Posté par pmeunier le 25 avril 2019 à 14:47. Évalué à 2.
  La démarche de Pijul est intéressante (Je verrais bien cet algo mis dans Git un jour).
  
  Les gens de Mercurial semblent y travailler, mais sans la commutation, c'est à mon avis nettement moins intéressant.
  
  Néanmoins, ce que j'aimerais c'est un DVCS qui gère assez simplement les fichiers binaires ou du moins les fichiers "zip" comme les documents LibreOffice.
  
  Il y a plusieurs difficultés :
  - LibreOffice stocke son format en XML avant de le compresser. Pijul a besoin d'une structure de base du document, et d'opérations atomiques dessus. Sur une liste de lignes, c'est facile. Sur un arbre (XML), il faut travailler un peu plus. Ceci dit, comme XML stocke ses arbres dans des fichiers, on peut quand même faire un diff balise par balise au lieu de ligne par ligne.
  - Représenter les conflits à l'utilisateur est sans doute assez compliqué, mais on peut y réfléchir.
  - Les fichiers compressés/binaires ont parfois tendance à changer un peu partout à la fois, et sont peu structurés, donc on peut difficilement gérer les conflits efficacement.
  En gros, on est ouvert à des contributions là-dessus ! https://discourse.pijul.org permet d'en discuter, et on peut t'aider à faire tes premiers patchs ;-)
- [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
  
  Posté par bnurb le 25 avril 2019 à 15:03. Évalué à 2.
  
  Je trouve git plutôt bon sur ce point, en jouant avec le .gitattributes et la config de git c'est possible. La doc est là.
  
  L’idée est de convertir les fichiers décris dans le .gitattributes en texte avec l'outil qui va bien. Ce dernier étant définit via la propriété textconv dans la config git.
  
  Par exemple, pour un fichier zip, on peut utiliser unzip -l comme textconv, ensuite les git diff, git show et autres, afficheront les différences entre les noms de fichier contenus dans les fichiers zip.
  
  Je rappel tout de même que, versionner du binaire reste dans 99.999% des cas… Une idée de merde ;).
- [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
  
  Posté par Fulgrim le 26 avril 2019 à 17:13. Évalué à 2.
  
  Git lfs (https://git-lfs.github.com/) ferait pas le taf pour toi ? C'est pas très contraignant si tu ne veux pas vraiment des diffs entre tes fichiers binaires.
- [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
  
  Posté par Matthieu Moy (site web personnel) le 26 avril 2019 à 18:18. Évalué à 5.
  
  Sur le cas particulier de LibreOffice, tu as en plus de la solution .gitattributes citée plus haut la solution de sauver en .fodt (OpenDocument Flat XML Document), qui est un peu plus VCS-friendly que le .odt de base : un fichier XML à plat au lieu d'une archive ZIP, donc une delta-compression plus efficace et un diff vaguement lisible (vaguement, hein …).
  - [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
    
    Posté par Maxzor le 28 avril 2019 à 20:12. Évalué à 3.
    
    Faire du textconv de .odt/.docx/.xlsx et differ du xml avec git ça n'a aucune valeur on est d'accord :)
    
    Le premier qui permet des diffs graphiques sur des word processor, tableur et gestionnaire de diapos a une killer feature pour moi.
    Si c'est microsoft il se feront encore un paquet de fric.
    Si c'est du logiciel libre il y a la gloire à la clé :D
    
    Franchement, il faut s'imaginer l'abomination du monde de l'entreprise actuel, les cabinets de conseils du big four &co. qui bossent avec l'immonde sharepoint et son versionnage de l'âge de pierre… Ca me fait déprimer tous les jours.
    - [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
      
      Posté par El Titi le 29 avril 2019 à 19:21. Évalué à 4.
      
      Après avoir réinventé les workspaces séparés du repo, le lock exclusif de fichiers pour certains type non mergeable (comme les images ou les storyboards), le stockage des gros objets dans un format de sérialisation différent en dehors de l'historique, tout ça grâce à Git LFS,
      … simplement parce que tout le monde utilise git en centralisé, gageons qu'ils vont avoir la bonne idée d'homogénéiser les types de fichier en créer des type manager pour gérer le merge/la comparaison /et le stockage des fichiers qui ont leur propres spécificités:
      https://www.ibm.com/support/knowledgecenter/en/SSSH27_9.0.1/com.ibm.rational.clearcase.cc_ref.doc/topics/type_manager.htm
      
      Encore un petit effort et on aura bientôt les vues dynamiques pour la CI et on pourra enregistrer la recette de fabrication des objets dérivés (le version de chaque fichier impliqué dans le build d'un objet) et on optimisera les builds entre différentes branches en réutilisant ces objets dérivés mis en cache.
      
      Encore un petit effort et il vont nous mettre une db pour optimiser le stockge de tout ça à coté.
      
      Encore un petit effort et après avoir épluché toutes les solutions bancales (submodules, subtree, …) pour gérer plusieurs repos dans la même vue logique et qui faisaient finalement la force de Bitkeeper il vont réinventer les config spec ou leur équivalent Perforce.
      
      Encore un effort et git évoluera vers un modèle décentralisé plutôt que distribué ou chaque site distant aura la maîtrise sur certaines branches plutôt que de confier ça à un seul intégrateur (https://www.ibm.com/support/knowledgecenter/es/SSSH27_7.1.1/com.ibm.rational.clearcase.cc_ms_admin.doc/c_mstrshp_branch.htm). Et aussi parce que les forges (non distribuées elles) ont complété ce modèle incomplet avec des garde-fous sur les branches (webhook) pour pallier tout ça. (Le modèle méritocratique à la Linux en entreprise y'en a qui l'ont déjà vu sérieux ?). Et puis parce que bon les hooks coté client … voilà
      
      Et on se dira qu'en fait plutôt que de se faire chier à gérer un simple cache d'historique (le D de DVCS) explicitement, on aurait pu utiliser un vrai cache qui n'oblige pas à cloner 1 repo de 5 Go qui t'oblige à faire des contorsions quand on se prend ça:
      https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed
      
      Et on réinventera Perforce ou Clearcase en new gen.
      
      Welcome back to the future :)
      
      A oui j'oubliais Git n'est pas un un outil de gestion de conf juste un "content manager" qui disaient !
      
      Et dire qu'on est même pas vendredi.
      - [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
        
        Posté par Dafyd le 03 mai 2019 à 20:46. Évalué à 3.
        
        C’est ça qui me rend fou. Au travail, les dev ont fait des pieds et des mains pour passer d’UCM ClearCase à Git, car ClearCase c’est pas moderne, c’est pas sexy, c’est pas en local sur leur PC, etc..
        
        Et maintenant que c’est fait, ils tombent de l’arbre :
        -> Ben, comment ça Git aime pas les gros binaires ?
        -> Pourquoi commiter des liens symboliques ça fait des trucs bizarres ?
        -> Euh, pourquoi ce merge a shooté 1 semaine de travail ?
        -> Euh, dit, pourquoi j’ai trois branches du même nom dans l’historique alors qu’on a mergé ?
        -> Comment je gère mes composants logiciels ? Les submodules ça fait pas ce qu’on veut… y’a pas moyen d’avoir des config spec ?
        
        Et donc après une tétrachiée d’outillages bancals par dessus, nous voilà avec un clone du pauvre de ClearCase. C’est le progrès.
        
        Moi je garde ma VOB, merci ;)
        
        [^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
        
        Posté par reno le 10 mai 2019 à 15:03. Évalué à 2.
        
        Bah, des gouts et des couleurs..
        J'ai été admin ClearCase il y a longtemps mais je préfère git! Je détestais les configspec..
        Et plus besoin d'avoir un serveur hyperlourd et souvent surchargé, j'aime beaucoup le D dans DVCS.
        
        Ceci dit je n'ai pas besoin de stocker des gros binaires..
# Bravo !

Posté par Ririsoft le 26 avril 2019 à 18:21. Évalué à 6.

Bravo Pierre-Étienne pour votre remarquable travail.

C'est un vrai challenge que de proposer une alternative à Git, mais le projet me semble bien parti.

M'étant mis à Rust je regarde Pijul évoluer depuis quelqu'un temps, sans m'y être vraiment mis. Ma crainte principale n'est pas liée à Pijul directement mais à la jeunesse de l'implémentation en Rust de certains algos et protocoles de sécurité comme l'implémentation de ssh via votre projet Thrussh.

Mais cet article m'a donné envie de m'y mettre beaucoup plus sérieusement. Je ne manquerai pas de venir vous voir sur Nest si besoin !

Bon vent à vous.
- [^] # Re: Bravo !
  
  Posté par pmeunier le 27 avril 2019 à 19:42. Évalué à 3.
  
  la jeunesse de l'implémentation en Rust de certains algos et protocoles de sécurité comme l'implémentation de ssh via votre projet Thrussh.
  
  C'est compréhensible. Je t'invite quand même à examiner le code des différentes implémentations de SSH pour te faire une meilleure idée (Thrussh, OpenSSH, LibSSH).
  
  Thrussh n'a pas eu la même quantité de tests que d'autres, mais le code suit à la lettre l'automate du protocole, avec une notion d'état encadrée assez strictement par l'API du crate Rust Tokio. Et Rust évite un paquet d'erreurs de C.
  - [^] # Re: Bravo !
    
    Posté par Ririsoft le 29 avril 2019 à 08:56. Évalué à 1.
    
    Je prend le point. Ma remarque s'applique tout autant aux autres librairies orientées sécurité de l'écosystème Rust. J'avais eu la même appréhension avec l'implémentation SSH de Go au début, mais maintenant je l'utilise sans crainte. Il en sera certainement de même avec Trustssh dans le temps !
- [^] # Re: Bravo !
  
  Posté par flan (site web personnel) le 10 mai 2019 à 09:36. Évalué à 3.
  
  Pas mieux !
  
  J'aime beaucoup l'idée d'avoir des preuves mathématiques derrière les outils que j'utilise.
  J'avoue que je suis pas mal tenu par git (GitHub et les IDE que j'utilise — ce sont d'ailleurs les seules raisons pour lesquelles j'utilise git), mais ça donne envie d'essayer.
# Exemples concrets?

Posté par Jehan (site web personnel, Mastodon) le 27 avril 2019 à 17:05. Évalué à 10. Dernière modification le 27 avril 2019 à 17:09.

Coucou,

J'ai vachement hésité avant d'écrire ce commentaire car je vois bien que vous êtes un peu sur la défensive. Je le comprends, c'est pas facile d'être sans cesse comparé par des gens qui comprennent pas votre techno à une autre techno plus connue (bon en même temps, c'est un peu votre faute aussi; vous lancez la discussion/comparaison dès le second paragraphe de l'article et dès le début du lien "Why Pijul"! Donc on a l'impression que votre principal atoût vient de la comparaison avec git). Mais c'est justement ça le prob. On comprends pas suffisamment pour appréhender l'avancée technologique.

Quand d'autres demandent des exemples, c'est pas pour vous prendre en défaut donc le prenez pas mal. En tous cas moi c'est pas le cas donc je réitère la question posée par d'autres: pourrait on avoir des exemples concrets ? J'ai bien vu les multiples réponses à cette question mais il me semble qu'aucune ne répond vraiment. On veut vraiment un exemple bête et méchant de la vraie vie.

Genre vous donnez 2 patchs (avec explicite diff) et vous montrez comment git le gère différemment (et surtout mal dans un cas) selon l'ordre (puisque l'un des points de vos algos est que l'ordre ne change pas le résultat contrairement à git). Puis vous montrez que pijul lui le fait bien dans tous les cas.
Autre exemple: un merge de 2 patchs qui génère un conflit avec git alors que pijul donne le résultat attendu sans conflit.

Ou bien d'autres exemples qui correspondent mieux aux problèmes résolus par Pijul (les miens sont peut-être mauvais mais justement c'est parce que j'ai du mal à comprendre; en tous cas en lisant plus haut, c'est ce que je comprends être les 2 gros problèmes réglés pas Pijul).

Clairement je trouve ça intéressant. Comme tout le monde j'ai eu mes emmerdes avec des conflits de merge foireux dans git, etc. Aussi je suis complètement techno-agnostique. git marche plutôt bien et j'en suis globalement content mais si demain un truc fait 10 fois mieux, j'aurai aucun remords à changer. Pourquoi pas?!
Donc je suis vraiment en train de demander naïvement des détails pour comprendre Pijul.
Car les algos prouvés scientifiquement c'est cool mais au final c'est pas ce que je vois en tant que dev de base. Me dire que "les patchs commutent" ou "sont associatifs", j'ai beau avoir fait des maths et comprendre plus ou moins ce que ça veut dire dans un contexte de système de versionnement, j'ai quand même du mal à voir ce que ça m'apporte concrètement pour mon boulot de dév au quotidien. D'ailleurs je pense faire partie des gens qui savent plutôt bien utiliser git et pourtant j'en connais pas les algos (comme vous l'expliquez très bien dans d'autres commentaires que la plupart des gens ne savent pas comment ça marche en interne; c'est vrai. Ça nous empêche pas de l'utiliser suffisamment efficacement pour nos besoins au quotidien). Ce qui prouve que l'usage final compte beaucoup (même si évidemment les algos aussi; et je suis parfaitement conscient à quel point ça doit être frustrant pour des chercheurs d'avoir l'impression que peu s'intéressent à la beauté de votre algo! J'en suis désolé!). Je fais partie de ces ingés simples qui font plutôt des implémentations pratiques d'algo d'ailleurs (en ce moment je bosse même pour le CNRS pour implémenter des algos dans GIMP). Je suis sûrement pas le meilleur dev du monde mais je pense pas être trop mauvais non plus. Donc je me dis que si je trouve pas ça si "intuitif", c'est que ça l'est peut-être pas autant que vous semblez le croire (ce qui ne veut pas dire que c'est mauvais pour autant!).

Et oui je me rends bien compte que je marche sur beaucoup d'œufs dans mon commentaire (ce qui le rend super long) mais c'est parce que j'ai l'impression qu'à chaque fois que quelqu'un compare à git ou vous demande des exemples, vous vous sentez attaqués. Franchement c'est pas le cas. Pour parler de mon cas personnel, je trouve juste sincèrement l'explication floue. J'ai l'impression que vous présentez une super techno du futur mais que je comprends rien à ce qu'elle apporte (de mieux que ce qui existe) en vrai… Hormis d'être une techno du futur!
Donc j'essaie d'y aller le plus diplomatiquement possible pour m'éviter de me prendre vos foudres ou que vous vous sentiez insultés. J'espère que ça marche, que vous le prendrez donc pas mal et m'apporterez des exemples concrets!
Merci! :P

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
- [^] # Re: Exemples concrets?
  
  Posté par pmeunier le 27 avril 2019 à 19:30. Évalué à 5.
  J'ai vachement hésité avant d'écrire ce commentaire car je vois bien que vous êtes un peu sur la défensive.
  
  Ce n'est pas tout-à-fait exact. J'ai dû faire un peu de défense face à des commentaires de mauvaise foi. Et je comprends aussi qu'il est difficile de se défaire de ses préjugés, et qu'une maîtrise raisonnable de Git (personne ne le maîtrise vraiment à fond, parce qu'il fait des trucs aléatoires de temps en temps sans vraie raison) prend du temps et de l'énergie.
  
  Car les algos prouvés scientifiquement c'est cool
  
  Git est prouvé "scientifiquement", c'est-à-dire qu'il a été amélioré pragmatiquement au fil des années jusqu'à ce que des gens arrivent à s'en servir. Par contre, parfois il mélange des bouts de fichiers, et si on a le malheur de ne pas respecter ses "bonnes pratiques" et autres "workflows", il devient rapidement inutilisable.
  
  Pijul est prouvé mathématiquement, ce qui veut dire qu'il implémente dans 100% des cas des axiomes mathématiques qu'on espère conformes à l'intuition.
  
  Genre vous donnez 2 patchs (avec explicite diff) et vous montrez comment git le gère différemment (et surtout mal dans un cas) selon l'ordre
  
  Comme je l'ai dit dans d'autres commentaires, l'ordre n'est pas le seul problème.
  
  Et la page du manuel "Why Pijul" a bien un lien vers un exemple concret avec du code C, où Git s'emmêle les pinceaux (en termes mathématiques, où Git n'est pas associatif) : https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html
  
  Sur la commutativité, tu as des exemples tout le temps quand tu utilises Git :
  - Chaque fois que tu créés une branche dans Git : 99% des branches de Git se traduisent simplement par des patchs dans Pijul, vu que les patchs que tu pourrais faire en parallèle commutent toujours : pas besoin de les séparer, il seront séparables à n'importe quel moment dans le futur.
  - Chaque fois que tu fais un rebase d'une branche sur une autre. C'est une opération qui n'est jamais nécessaire dans Pijul, elle est automatique dans 100% des cas.
  - Rebase a d'autres usages, comme par exemple retirer un vieux commit. Pijul fait ça (la commande est unrecord) sans changer l'identité des nouveaux commits, donc si tu as déjà poussé ce n'est pas grave.
  Comme tout le monde j'ai eu mes emmerdes avec des conflits de merge foireux dans git,
  
  C'est un autre problème que Pijul n'a pas, il y a une vraie représentation interne des conflits.
  
  Ça nous empêche pas de l'utiliser suffisamment efficacement pour nos besoins au quotidien.
  
  Comme je l'ai déjà dit dans une autre réponse, si tu te sens efficace quand tu utilises Git, c'est très bien ! Peut-être que Pijul n'est pas pour toi.
  
  Git a ses qualités, que j'apprécie. Je pense par exemple que dans un cas où on n'a jamais besoin de merge, c'est un outil quasiment parfait. Mais pour travailler à plusieurs sur du code ou des articles, c'est un outil qui fait perdre du temps à plein de gens. Il en fait évidemment gagner par rapport à ne pas utiliser de contrôle de version, utiliser Dropbox, SVN, des mails, mais je crois qu'il en fait perdre énormément par rapport à Pijul.
  
  Ce qui prouve que l'usage final compte beaucoup
  
  J'en suis convaincu, et c'est la raison d'être de Pijul.
  
  L'idée est que si un outil répond à un raisonnement simple, déterministe, avec peu de commandes qui permettent de tout faire et marchent bien ensemble, je pense que son "usage final" sera plus facile qu'un outil à 150 commandes et 10000 options, dont les utilisateurs parodient le manuel : https://git-man-page-generator.lokaltog.net/
  - [^] # Re: Exemples concrets?
    
    Posté par Jehan (site web personnel, Mastodon) le 27 avril 2019 à 20:57. Évalué à 10.
    
    Ce n'est pas tout-à-fait exact. J'ai dû faire un peu de défense face à des commentaires de mauvaise foi.
    […]
    Comme je l'ai déjà dit dans une autre réponse, si tu te sens efficace quand tu utilises Git, c'est très bien ! Peut-être que Pijul n'est pas pour toi.
    
    Hmmm… tout de même avec toutes les précautions que j'ai prises, cette réponse arrive quand même à être pas mal sur la défensive! Je pense avoir suffisamment expliqué que j'étais ouvert aux nouveautés. Et dire que j'aime bien/suis efficace avec git ne signifiait absolument pas que je ne veux pas de Pijul ou que ce n'est pas pour moi. Si c'est le cas, aurais-je vraiment écrit un super long message super diplomatique qui m'a pris du temps?
    Peut-être serais-je encore plus efficace avec Pijul, qui sait! Ce n'est donc pas antithètique (être efficace avec git vs. Pijul est pour moi? Aucun rapport, fils unique!). 😛
    
    Et la page du manuel "Why Pijul" a bien un lien vers un exemple concret avec du code C, où Git s'emmêle les pinceaux (en termes mathématiques, où Git n'est pas associatif) : https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html
    
    Ok j'avais loupé ça, c'est intéressant, merci. L'exemple aurait mérité d'être recopié avec un joli formatage dans la dépêche, en bien placé. D'un seul coup on comprend beaucoup mieux et tu te serais évité pas mal de discussions, je pense!
    
    C'est pour moi 100 fois plus explicatif que tous les mots mathématiques ou que les détails sémantiques (genre définir prouvé "scientifiquement" vs "mathématiquement"; désolé mais bon… 😛).
    
    Sur la commutativité, tu as des exemples tout le temps quand tu utilises Git :
    
    Encore une fois, un exemple concret ne serait pas de refus (tes 3 points ne sont pas des exemples concrets pour expliquer un tel usage). En un exemple, le coup de l'associativité est devenue concrête en 2 minutes de lecture (évitant ainsi de longs débats sur linuxfr). Ça vaudrait le coup de faire pareil avec la commutativité, non? :-)
    
    Chaque fois que tu fais un rebase d'une branche sur une autre. C'est une opération qui n'est jamais nécessaire dans Pijul, elle est automatique dans 100% des cas.
    
    Tiens là par exemple j'ai vraiment du mal à comprendre ce que tu me dis. Comment la branche peut-elle être rebasée sans demande explicite? Comment sait-elle sur quelle autre branche elle doit l'être? Et si je veux pas rebaser? Enfin bon là comme ça, ça me paraît juste magique. Ensuite y a sûrement une logique que je ne pige pas. D'où: un exemple concret serait utile.
    
    Rebase a d'autres usages, comme par exemple retirer un vieux commit. Pijul fait ça (la commande est unrecord) sans changer l'identité des nouveaux commits, donc si tu as déjà poussé ce n'est pas grave.
    
    Mais tu le retires-retires? Il n'est plus disponible du tout, plus de trace dans l'historique (genre pas comme un git revert où tu annules l'action du commit sans retirer dans l'historique)?
    C'est tout de même assez tendancieux de permettre la réécriture à volonté (pour les branches publiques, notamment communément celle appelée "master" dans git). Et ce n'est pas seulement car on casse l'historique dans git (les hashs de commit qui ne sont pas cassés dans Pijul, j'ai bien compris cette partie!), mais bien aussi car réécrire l'histoire, c'est perdre des informations. Aussi les gens avec un vieux hash de commit ne peuvent plus le retrouver. Les seuls cas considérés comme acceptables sont normalement lorsqu'on a "commité" des infos méga-confidentielles par erreur (et encore… en général si on a fait ça, il faut surtout considérer que c'est trop tard cas on ne sait pas qui en a pris connaissance; donc réécrire l'histoire ne sert en général à rien, même dans ce cas, à part limiter les dégâts éventuellement le temps de changer les infos fuitées à la source).
    
    C'est un autre problème que Pijul n'a pas, il y a une vraie représentation interne des conflits.
    
    C'est un truc que tu as répété plusieurs fois dans tes commentaires. Et c'est aussi écrit dans la page "Why Pijul". Mais ça veut dire quoi concrêtement une "vraie représentation interne des conflits", pour nous autres simples développeurs qui veulent juste versionner nos sources?
    
    ⚠ Je ne te demande pas de me le réexpliquer avec d'autres mots, et surtout pas des termes mathématiques! ⚠
    Encore une fois, un exemple concret vaut tous les discours. Genre un copier-coller du résultat d'un conflit de merge, et comment il est corrigé par le développeur qui utilise Pijul (genre le workflow avec les diverses commandes Pijul; qu'est-ce que le dév voit dans ses fichiers? comment les modifie-t-il? etc.). Ça, je pense que je comprendrais. :-)
    (et cette fois j'ai bien regardé si j'ai pas loupé un lien sur la page "Why Pijul? qui donne un tel exemple; et il me semble que non, ou alors c'est bien caché!)
    
    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
    - [^] # Re: Exemples concrets?
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 28 avril 2019 à 08:53. Évalué à 7.
      
      J'ai regardé les anciens contenus linuxfr tagués pijul, je suis tombé sur Hacker News, puis sur ce lien: https://jneem.github.io/archive/
      
      Il y a quatre postes de blog assez long, mais qui m'ont l'air mieux formaté et plus concret :)
      - [^] # Re: Exemples concrets?
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 29 avril 2019 à 10:30. Évalué à 10.
        
        Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
        
        Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
        
        Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
        
        Le patch dépend d'un fichier source
        
        Le patch travaille ligne par ligne (et non pas mot par mot)
        
        Un patch peut ajouter des lignes, mais ne pas les modifier
        
        Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
        
        Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
        
        Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
        
        Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
        
        Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
        
        Ecrire les graggles de A et B l'un à côté de l'autre
        
        Quand une ligne de A et de B partagent le même parent, fusionnez les parents en une seule ligne.
        
        A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
        
        Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
        
        Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
        
        J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
        
        En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
        
        Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
        
        Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
        
        Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
        
        Il a écrit dans un commentaire plus bas:
        
        … mais quand même tous les algos qui marchent, pour la première fois !
        
        Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
        Bravo !
        
        Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles…
        
        PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.
        
        [^] # Re: Exemples concrets?
        
        Posté par pmeunier le 29 avril 2019 à 19:27. Évalué à 7.
        
        J'aime bien ton résumé.
        
        les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
        
        Oui, si je savais régler tous les conflits sur un texte tout en satisfaisant tout le monde, je n'aurais pas écrit un logiciel, mais une lettre de motivation pour le Nobel de la paix.
        
        Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
        
        Tu as bien compris. Je n'ai annoncé ni une version 1.0, ni une version méga-optimisé, ni une doc de ouf. Juste le fait qu'on était enfin rassuré sur le fait que c'est possible. Florent et moi avons parlé de ce projet pour la première fois en Janvier 2014, on a commencé à l'implémenter à l'automne 2015 (on est resté bloqué longtemps parce qu'on n'avait pas de Sanakirja, et plein d'autres choses à faire).
    - [^] # Re: Exemples concrets?
      
      Posté par pmeunier le 28 avril 2019 à 12:52. Évalué à 5.
      Peut-être serais-je encore plus efficace avec Pijul, qui sait! Ce n'est donc pas antithètique (être efficace avec git vs. Pijul est pour moi? Aucun rapport, fils unique!). 😛
      
      D'abord, je ne me suis pas du tout senti "attaqué" par ton commentaire. J'essaie en général d'être rigoureux et concis dans mes réponses (et j'aime bien Git, je l'ai déjà dit).
      
      D'autre part, Pijul étant significativement plus simple que Git, il n'est souvent pas complètement évident pour nous d'écrire de la doc. Pour avoir appris Pijul à des gens autour de moi, il me semble que la principale difficulté consiste à oublier les workflows, les bonnes pratiques, etc. Mais nous sommes complètement ouverts à des contributions, en particulier sur la documentation, comme tu peux le voir sur https://nest.pijul.com/pijul_org/manual/patches.
      
      Je pense qu'une bonne façon de voir des exemples concrets, c'est d'essayer. Effectivement, le manuel n'est pas écrit en pensant aux gens qui vont vouloir comprendre tout Pijul sans jamais l'essayer, mais plutôt aux gens qui l'essaient et veulent comprendre comment ça marche (et pourquoi ça marche dans 100% des cas).
      
      Je te suggère d'essayer tous les trucs dont j'ai parlé ici :
      
      essaie d'utiliser Pijul sans faire de branches. Ne fais que des clones dans un premier temps. Les branches de Pijul sont des clones rapides, mais comme la copie de travail est au même endroit, utiliser les branches peut cacher des trucs.
      
      essaie de pousser tes patchs sur https://nest.pijul.com, et fais des unrecord de vieux patchs dans l'onglet "patchs",
      
      essaie de faire des pull entre dépôts locaux sans prendre tous les patchs (du cherry-picking implicite).
      
      essaie de faire des conflits, d'éditer juste un côté et de faire record et push. Ensuite, dans un autre dépôt, pull seulement les patchs relatifs au côté que tu as édité. (A et B sont en conflit, C édite le morceau introduit par A. Pull juste A et C dans un dépôt séparé).
      
      Tiens là par exemple j'ai vraiment du mal à comprendre ce que tu me dis. Comment la branche peut-elle être rebasée sans demande explicite?
      
      Exemple concret d'un rebase d'une branche sur une autre : tu as une branche Git A, forkée depuis une branche Git B.
      
      Pour faire plus concret:
      
      - y - z / --- x -- u - v
      
      Et tu veux la rebaser :
      
      - y - z / --- x -- u - v
      
      Dans Pijul, cette opération est parfaitement inutile, vu que les branches sont juste des patchs (il y a aussi un truc qui s'appelle "branche" dans Pijul, ce n'est pas la même chose). Dans Pijul, tu as juste deux ensembles de patchs, { x, y, z } et { x, u, v }. Si tu veux, tu peux appliquer un patch sur l'un des deux : { x, y, z, u }. Il n'y a pas d'opération spéciale pour faire ça, c'est juste appliquer un patch qui est dans une autre branche. Tu n'as pas besoin de réfléchir à la disposition de tes branches en le faisant.
      
      Et tu pourras toujours revenir en arrière plus tard, même après avoir appliqué d'autres patchs. Concrètement : si tu as { x, y, z, u, a, b }, et que tu te rends compte que tu ne voulais pas u, ce que tu veux faire est "enlever u de l'ensemble", pas "dire que le parent de a devient z, puis essayer d'inverser le diff entre z et u".
      
      Je suis d'accord que ça ne fait aucune différence sur les exemples simplifiés sur lesquels on explique généralement Git. Mais si tu imagine que u était en fait un merge avec conflit, qu'il a fallu plusieurs heures de travail d'un ingénieur cher pour résoudre les conflits et fabriquer u, et qu'on va peut-être vouloir le reprendre plus tard, tu peux imaginer le temps et l'argent perdu (par rapport à Pijul).
      
      Et comme je l'ai déjà dit dans d'autres réponses, le modèle de Git oblige l'utilisateur à recharger un modèle mental du dépôt dans sa mémoire avant de commencer à taper des commandes. Ça n'a aucun inconvénient si ce modèle est simple (une seule branche, chaque commit ajoute une ligne, pas de conflits). Ça peut prendre du temps dans les autres cas. On pourrait répondre "oui mais tu vas bien devoir connaître ton dépôt quand même, pour travailler avec". Mon expérience (et celle des utilisateurs de Darcs et Pijul) est que c'est dû aux contraintes internes de Git, et que ce n'est souvent pas nécessaire.
      
      Mais tu le retires-retires? Il n'est plus disponible du tout, plus de trace dans l'historique (genre pas comme un git revert où tu annules l'action du commit sans retirer dans l'historique)?
      
      Ça reste un patch écrit dans un fichier, donc il existe encore, il n'est juste plus dans le dépôt. On peut le réappliquer.
      
      C'est tout de même assez tendancieux de permettre la réécriture à volonté (pour les branches publiques, notamment communément celle appelée "master" dans git). Et ce n'est pas seulement car on casse l'historique dans git (les hashs de commit qui ne sont pas cassés dans Pijul, j'ai bien compris cette partie!), mais bien aussi car réécrire l'histoire, c'est perdre des informations.
      
      Le morceau de mon commentaire auquel tu réponds ici était juste un exemple d'utilisation de rebase autre que "rebaser une branche sur une autre" dans Git.
      
      J'ai déjà dit dans plusieurs autres commentaires que Git perdait de toute façon un peu d'informations en imposant la même histoire à tout le monde une fois un merge fini, alors qu'il y a eu en vrai ("concrètement") plusieurs histoires différentes qui ont produit la même chose.
      
      En d'autres termes: Alice et Bob travaillent ensemble, Alice fait un patch A, Bob fait un patch B en parallèle. Après le merge, Git dit juste "A et B ont été fusionnés", alors que Pijul dit "Alice a appliqué A, puis B" et "Bob a appliqué B, puis A", et on a la garantie que les deux ont exactement la même chose dans 100% des cas.
      
      Aussi les gens avec un vieux hash de commit ne peuvent plus le retrouver. Les seuls cas considérés comme acceptables sont normalement lorsqu'on a "commité" des infos méga-confidentielles par erreur (et encore… en général si on a fait ça, il faut surtout considérer que c'est trop tard cas on ne sait pas qui en a pris connaissance; donc réécrire l'histoire ne sert en général à rien, même dans ce cas, à part limiter les dégâts éventuellement le temps de changer les infos fuitées à la source).
      
      J'ai l'impression que tu parles de bonnes pratiques Git. Je ne sais pas encore ce que peut être une bonne pratique dans Pijul, ni comment les gens vont vraiment l'utiliser. Git a plein de bonnes pratiques et de trucs "considérés comme acceptables" à cause de contraintes techniques, je ne sais pas quelles "bonnes pratiques" resteraient si on enlevaient ces contraintes (et je ne pense pas que quelqu'un puisse le savoir sans avoir essayé concrètement dans la vraie vie).
      
      Mais ça veut dire quoi concrêtement une "vraie représentation interne des conflits", pour nous autres simples développeurs qui veulent juste versionner nos sources?
      
      Ça veut dire que dans Pijul, un conflit n'est pas juste une erreur de fusion, c'est un état normal. Tu peux par exemple éditer l'un des côtés du conflit sans le résoudre, ou encore partager la résolution du conflit entre deux patchs sans avoir à partager tout le reste.
      
      Avec des noms sur les patchs, ça donne : si tu as deux patchs A et B qui sont en conflit (par exemple, A écrit "a" dans un fichier, et B écrit "b" au même endroit), tu peux produire un patch C qui résout ce conflit. N'importe qui qui a les deux patchs A et B va voir le même conflit (indépendamment des autres patchs qu'ils pourraient avoir, par exemple s'ils ont d'autres patchs D ou E). Et à partir du moment où tu as A, B, et C dans le même dépôt, ce conflit est résolu. Il ne reviendra pas (au revoir, git rerere!).
      - [^] # PUBLICATION JUDICIAIRE
        
        Posté par ZeroHeure le 29 avril 2019 à 12:00. Évalué à 10. Dernière modification le 12 mai 2019 à 00:57.
        
        PUBLICATION JUDICIAIRE
        
        Suite aux nombreux commentaires jugés « accusateurs » par l'auteur de Pijul, la cour de justice de l'équipe de modération s'est réunie en elle-même pour s'auto-saisir de l'affaire.
        
        De la lecture attentive des commits de modération il appert que les auteurs des phrases audacieuses comparant Git et Pijul, ou donnant une image trop flatteuse du projet, sont :
        
        Nycö, ci-devant président de l'association linuxfr.org, ce dont il tire gloire ;
        
        et ZeroHeure, modérateur de seconde zone incapable d'écrire une dépêche par an, tout juste bon à s'inventer des postes imaginaires.
        
        Considérant que les phrases ont été copiées au petit bonheur depuis le site web de Pijul, sans consulter l'auteur de Pijul et pourtant en son nom ;
        considérant qu'elles ont été beaucoup réécrites, notamment par Davy Defaud l'émérite correcteur de linuxfr.org, nonobstant ne pouvant prouver l'intention de dissimulation quant à leur provenance ;
        considérant que l'auteur de Pijul ne souhaitait publier qu'une notulette sans importance ;
        considérant les nombreuses questions et réponses éclaircissant la dépêche ;
        
        Nous, cour de justice de l'équipe de modération, réunie en nous-même dans le coeur et le cervelet de ZeroHeure, après enquête, délibération et libations (sic !) disons que :
        
        les corrections de Davy Defaud sont linguistiques, grammaticales et justifiées ;
        
        l'auteur de Pijul ayant pu s'expliquer, les commentaires ont largement enrichis la dépêche, donnant matière à une plus ample production ;
        
        la légèreté et le sérieux de Nyčo et ZeroHeure dans leurs interventions sur la dépêche ne font aucun doute ;
        
        la foi de Nÿco et ZeroHeure en la tradition enrichissante des commentaires de dépêche leur fait honneur ;
        
        Ñyco et ZeroHeure se sont abstenus de commentaires ou d'excuses voire de toute intervention dans les fils de discussion, même avec leurs multis, ce qui est blâmable.
        
        Et jugeons, commandons et recommandons :
        
        Ñŷçö et ZeroHeure sont condamnés aux dépend à se payer mutuellement une bière afin d'honorer leur rencontre prévue de longue date ;
        
        l'auteur de Pijul pourra librement se joindre à eux ;
        
        il ne sera pas tenu compte exact des tournées ;
        
        l'auteur de Pijul devrait écrire une longue dépêche dans la foulée ;
        
        ZeroHeure doit finir cette année ses dépêches en cours ou promises ;
        
        chaque dépêche publiée lui vaudra gratitude et karma ;
        
        l'entrée de nouveaux modérateurs ou trices est pressante.
        
        Écrit et validé en la huitième année de l'ère du Ruby (ça ne me paraissait pas si vieux).
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: PUBLICATION JUDICIAIRE
        
        Posté par pmeunier le 29 avril 2019 à 19:30. Évalué à 5.
        
        l'auteur de Pijul pourra librement se joindre à eux ;
        
        J'habite en Irlande… mais je boirais une Guinness à votre santé !
        
        l'auteur de Pijul devrait écrire une longue dépêche dans la foulée ;
        
        Ce sera fait bientôt. Les réactions ici même m'ont appris pas mal de choses, merci à tous les participants (et n'hésitez pas à continuer) !
        
        [^] # Re: PUBLICATION JUDICIAIRE
        
        Posté par ZeroHeure le 30 avril 2019 à 15:00. Évalué à 6. Dernière modification le 30 avril 2019 à 15:01.
        
        Au fait, tu as tendance à répondre en décrivant un exemple tandis que les commentaires réclament un exemple "visuel". Par exemple El Titi montre ses exemples et tu lui réponds « Si Alice décidait d'écrire En voici du sur la première ligne, et Bob décidait d'écrire Et ron et ron au lieu de Et patati et patata, alors… » Au lieu de faire "visuel" :
        
        Si Alice décidait d'écrire
        
        En voici du blabla Et patati et patata
        
        et Bob décidait d'écrire
        
        En voilà du blabla Et ron et ron
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: PUBLICATION JUDICIAIRE
        
        Posté par pmeunier le 30 avril 2019 à 16:52. Évalué à 4.
        
        Ok, merci pour la remarque. Faire l'un et l'autre semble être une bonne idée.
      - [^] # Re: Exemples concrets?
        
        Posté par El Titi le 13 mai 2019 à 20:31. Évalué à 2.
        
        Avec des noms sur les patchs, ça donne : si tu as deux patchs A et B qui sont en conflit (par exemple, A écrit "a" dans un fichier, et B écrit "b" au même endroit), tu peux produire un patch C qui résout ce conflit. N'importe qui qui a les deux patchs A et B va voir le même conflit (indépendamment des autres patchs qu'ils pourraient avoir, par exemple s'ils ont d'autres patchs D ou E). Et à partir du moment où tu as A, B, et C dans le même dépôt, ce conflit est résolu. Il ne reviendra pas (au revoir, git rerere!).
        
        J'avoue que ça reste encore un peu flou, alors j'essaye de détailler.
        Afin de lever toute ambiguïté, je te propose d'utiliser la terminologie suivante (Je sais que vous y réfléchissez encore et j'ai pas mal cogité et bidouillé de mon côté ;-) :
        
        Toute branche au sens de Pijul est appelée ensemble car ce n'est ni plus ni moins que ça - un ensemble de patchs (change) atomiques et de séquences de patch (interdépendants et ordonnés) -.
        
        Par exemple, si on a 2 sous-ensembles dans notre dépôt:
        e1={A} et e2={A, D<-E}.
        Chacune de ces entités (unités de changement ou séquences) commutent entre elles. On a, de par la commutativité:
        {A, D<-E} == {D<-E, A} != {E<-D, A}
        (Une séquence ne commute pas entre ses propre constituants mais commute avec les autres entités).
        
        Jusque là, j'ai juste ?
        
        Admettons que l'on incorpore un nouveau change ( pijul pull ) B dans e1 qui entre en conflit et que l'on doive évidemment le résoudre avant de l'intégrer ce qui donne C comme dépendance. ( pijul dependencies)
        
        Si te je suis toujours, on obtient à présent:
        e1={A<-C->B}, e2={A, D<-E}
        
        Si j'incorpore les changes de e2 dans e1 ( pijul pull e2), je me retrouve avec
        
        e1={A<-C->B}, e2={A<-C->B, D<-E}
        On n'a donc pas eu à ré-effectuer la résolution par nous-même.
        
        C'est bien ça ?
        
        Ce que j'ai du mal à imaginer par contre, c'est un cas où le git rerere ou même le fait de rejouer le même conflit serait nécessaire ici.
        Sauf peut-être… si on a commencé à jouer avec des cherry-picks entre 2 branches de release. Et je ne vois pas non plus vraiment, dans quelles situations un rebase (vu en tant que suite de cherry-picks) redemanderait de ré-appliquer les mêmes conflits.
        Mais je conviens que l'approche de Pijul est élégante et moins hasardeuse.
        
        [^] # Re: Exemples concrets?
        
        Posté par pmeunier le 14 mai 2019 à 00:31. Évalué à 1.
        
        C'est exactement ça. Tu n'es pas allé assez loin pour avoir besoin d'un rerere.
        
        Pour simplifier un peu, on va dire que C ne fait que garder toutes les lignes de A et B, dans l'ordre où elles sont affichées.
        
        Maintenant, la personne qui a produit B continue à travailler, pour produire par exemple F (on pourrait dire que F change toutes les lignes introduites par B, et ne fait que ça).
        
        Elle a donc un dépôt e_3 = {B, F}. Si maintenant tu pulles son dépôt depuis e_2, tu vas te retrouver dans Pijul avec {A<-C->B, D<-E, F}, et dans Git avec un nouveau conflit sorti de nulle part, qu'un git rerere au moment de produire C aurait résolu.
        
        [^] # Re: Exemples concrets?
        
        Posté par El Titi le 14 mai 2019 à 08:40. Évalué à 2.
        
        Je m'excuse mais tu m'as perdu.
        
        Pour rappel sur ton exemple:
        
        (par exemple, A écrit "a" dans un fichier, et B écrit "b" au même endroit),
        
        A a produit "a"
        B a produit "b"
        
        C a résolu le conflit en "c" par exemple et a été résolu dans e2
        
        Si on reprend mon formalisme, la personne qui détient e3 est donc initialement dans l'état:
        e3={B}
        
        En introduisant un change sur les lignes de B, on modifie toujours la même ligne par exemple:
        pour lui "b" devient "tadaaa"
        
        Je correspond à ton exemple ici:
        
        Maintenant, la personne qui a produit B continue à travailler, pour produire par exemple F (on pourrait dire que F change toutes les lignes introduites par B, et ne fait que ça).
        
        On produit F avec "tadaa" à la place de "b"
        
        Lorsqu'il recorde dans e3, il a :
        e3={B<-F}
        et pas :
        
        e3 = {B, F}
        non ?
        
        Après, si on incorpore dans e2 on a forcément un conflit à résoudre aussi
        e2={A<-C->B, D<-E, B<-F}
        
        Je dois bien résoudre mon fichier qui contient actuellement "c" et il me demande de résoudre avec "tadaa"
        
        (je vais changer la notation pour récursive dans les dépendances)
        Il sera résolu en F avec "tutu"
        
        e2={ D<-E, F->(B, C->(A,B)) }
        
        Je vais essayer de le rejouer avec Pijul pour voir le résultat
        et essayer de comprendre.
        Je ne vois toujours pas le rapport avec rerere dans cet exemple mais je crois que je peux essayer d'en construire un autre. Je vais creuser.
        
        [^] # Re: Exemples concrets?
        
        Posté par pmeunier le 14 mai 2019 à 12:20. Évalué à 1. Dernière modification le 14 mai 2019 à 12:20.
        
        Oui, mais je parlais dans mon dernier commentaire d'un cas où git rerere est utile. Pour voir une différence entre Git et Pijul, il faut vraiment que C résolve le conflit en laissant les lignes de A et de B. { A, B, C } (désolé pour les dépendances) donne :
        
        a b
        
        Si C résout le conflit en supprimant les deux lignes, et que F fait autre chose, tu vas voir un nouveau conflit, quel que soit l'outil que tu utilises. C'est simplement parce que "tadaaa", ce n'est pas la même chose que "tadaa". Un outil qui ne verrait pas de conflit sur ce cas serait foireux.
        
        [^] # Re: Exemples concrets?
        
        Posté par El Titi le 14 mai 2019 à 15:11. Évalué à 2.
        
        Ok je crois que je je commence à piger.
        
        Au départ on a
        
        A:
        toto.txt
        a
        
        B:
        toto.txt
        b
        
        Après le 1er pull
        C résoud un conflit entre A et B et introduit une dépendance dans ton set,on a:
        e2={C->(A,B); E->D}
        avec:
        
        C
        toto.txt
        a
        b
        
        Dans e3 (l'autre user, on introduit un nouveau changement F ("b" devient "tadaa"). On a
        e3={F->B} avec;
        
        F:
        toto.txt
        tadaa
        
        Lorsqu'on pull dans e2 à nouveau on se retrouve avec:
        e2={C->(A,B); E->D, F->B} mais pour ton algo qui conserve un graphe de ligne même si B est une dépendance de C et F il ne considère pas ça comme un conflit est reconstruit la snapshot (le workspace) globale en :
        
        toto.txt
        a
        tadaa
        
        Il n'a pas besoin de construit un nouveau commit (automatiquement généré) pour le coup ?
        
        Git évidemment se vautre car il a 1 3 way avec comme
        
        base:
        (un commit antérieur à ceux qui ont introduit a et b résolu lors du 1er conflit qui peut contenir a ou b ou aucun des 2)
        
        ours:
        
        toto.txt
        a
        b
        
        theirs:
        
        toto.txt
        tadaa
        
        Je vais tester tout ça.
        Merci
    - [^] # Re: Exemples concrets?
      
      Posté par kantien le 30 avril 2019 à 13:06. Évalué à 10.
      ⚠ Je ne te demande pas de me le réexpliquer avec d'autres mots, et surtout pas des termes mathématiques! ⚠
      
      En complément du commentaire d'Adrien Dorsaz, je vais quand même essayer. Mais ne t'inquiète pas, ce sera des mathématiques simples : de l'arithmétique élémentaire avec les nombres entiers, et un peu de graphes.
      
      Une image que j'aime bien et qui représente des historiques possibles d'un dépôt est celle-ci :
      
      On peut résumer le cœur d'un gestionnaire de version à cette interface rudimentaire :
      
      type patch type state val commit : patch -> state -> state val merge : state -> state -> state
      
      Il y a deux concepts : les patchs et les états, puis deux fonctions pour appliquer un patch sur un état ou fusionner deux états. Ainsi, sur le graphe du dessus, on a par exemple :
      
      A = commit p O
      
      M = merge A B
      
      Plutôt que de travailler avec des fichiers et des répertoires, commençons plus simple et travaillons avec des entiers naturels. Les états (ou sommets du graphes) sont des entiers et les patchs sont aussi des entiers où la fonction de commit est la multiplication. Le graphe relie alors deux entiers s'ils sont multiples et l'arrếte est étiquetée par le coefficient multiplicateur. La fonction de fusion (merge) calcule le plus petit commun multiple.
      
      On peut par exemple partir de l'état initial 1 et prendre pour les trois patchs du graphes les nombres suivants : p = 2, q = 3 et r = 7. Je remets le graphe :
      
      On aura ainsi le sommet A = 2, le sommet B = 3 et leur fusion M = 6. Ce qu'exprime le graphe, c'est que quelque soit le chemin que l'on prenne pour fusionner ces trois patchs, on tombera toujours sur Q = 42. Cela parce que la multiplication est associative et commutative.
      
      La première propriété (associativité) n'est pas satisfaite par les autres CVS : fusionner A et N ou bien fusionner M et C ne donnera pas toujours le même résultat. C'est cela qu'illustre ces deux schémas dans la documentation de pijul :
      
      Le pire étant que ces CVS peuvent fusionner le tout, sans signaler de conflit, et faire n'importe quoi. Tel était l'exemple donné par Pierre-Étienne Meunier.
      
      Ensuite, à la place des nombres entiers, on peut prendre un Rubik's cube. Ici les états seraient ceux du cube, et le patchs les transformations qu'on peut lu faire subir. Avec un tel système, on aura toujours l'associativité des transformations. Que je fasse p ; (q ; r) ou (p; q) ; r cela ne change pas grand chose et l'on dit que l'on a effectué ces trois transformations à la suite p; q; r, sans mettre de parenthèses. Par contre, sur un rubik's cube, deux patchs ne peuvent pas toujours être appliqués dans n'importe quel ordre, lorsqu'ils bougent des zones communes. Dans ce cas, on dit qu'ils ne commutent pas. Il en est de même avec les CVS : des fois ça commute, des fois ça ne commute pas; mais pijul est capable de déterminer si deux patchs commutent ce qui lui permet (non de réécrire l'historique) mais de réécrire le graphe de dépendance entre les patchs pour faciliter la gestion du dépôt : on peut supprimer facilement l'effet d'un patch sans toucher aux modifications qui lui sont postérieures et indépendantes.
      
      Il reste un point à éclaircir : la représentation interne des conflits. Revenons au cas des nombres entiers ou la fonction de merge était le calcul de plus petit commun multiple. Et regardons, ce graphe :
      
      Ici, nos sommets sont toujours des entiers, M est le ppcm de A et B et F est un multiple quelconque de A et B, mais aussi un multiple de M. Ce que fait pijul c'est généraliser cette notion de ppcm aux fichiers. Pour cela, on considère un fichier comme une liste de lignes. Malheureusement, il n'y a pas toujours de ppcm pour deux fichiers : c'est le signe d'un conflit lors d'une fusion.
      
      La solution est de prendre un type plus riche que les liste pour les sommets du graphe : à savoir des graphes de lignes (dont les listes sont un cas particuliers). À ce moment là, deux graphes de lignes ont toujours un « ppcm » que l'on appelle leur fusion. Si ce graphe est similaire à une liste alors il n'y a pas de conflit sinon c'est qu'il y a conflit :
      
      If the two following conditions are both met:
      
      the graph is acyclic, and contains a path passing through all the vertices.
      
      for each vertex v, all incoming edges of v have the same label ("alive" vs. "deleted").
      
      Then the task of presenting the file to the user is relatively straightforward: just go along the path and output all alive vertices. Else, we say the file has a conflict, and presenting the state of the file to the user in an intelligible way is not obvious.
      
      pijul documentation
      
      Comme pijul travail avec des états qui sont ces graphes de lignes, il a une représentation interne des conflits (des graphes qui ne sont pas des listes) et peut travailler sur eux comme il le ferait avec des fichiers normaux : on peut leur appliquer des patchs, les fusionner… et les aplatir vers des fichiers (résoudre les conflits) quand on veut.
      
      D'une manière générale, j'aime bien ce principe : Theorise first then implement is the stairway to heaven. Implement first then theorise is the highway to hell. D'autant que Jimmy page était, sans nul doute ni contestation, bien plus fin et subtil qu'Angus Young. :-P
      
      Comme pijul a choisi la première voie, c'est plus simple et plus naturel; les autres systèmes reposant sur une mauvaise analyse de l'algèbre des patchs et des états.
      
      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
      - [^] # Re: Exemples concrets?
        
        Posté par Dring le 30 avril 2019 à 22:08. Évalué à 5.
        
        Ce commentaire doit être génial pour les personnes qui n'utilisent pas un fond sombre comme moi ! :'-(
        
        Bon, blague à part, je vais le lire quand même, mais je me faisais une remarque en lisant "ppcm". Mon premier réflexe a été "tiens, une typo dans un message de l'éminent kantien". N'en croyant pas mes yeux, j'ai fait la vérification dans wikipedia, et non, c'est bien "ppcm" pour "plus petit commun multiple". Et "pgcd" pour "plus grand commun diviseur".
        
        Je suis persuadé que lors de ma scolarité, le mot "commun" était situé en queue de peloton.
        
        Alors de deux choses l'une :
        - soit il y a un plan machiavélique de domination du monde par le mot "commun" pour se retrouver de plus en plus tôt dans toutes les phrases ; et d'ici quelques années, on dira "commun plus grand diviseur", "commun j'étudie le droit", "commun ça va", etc
        - soit j'ai commencé la picole dès la primaire
        
        [^] # Re: Exemples concrets?
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 30 avril 2019 à 23:54. Évalué à 2.
        
        J'avais aussi l'habitude de "plus petit multiple commun" à l'école obligatoire, puis à l'uni on a parlé de "plus petit commun multiple". Comme en français les adjectifs peuvent être placés n'importe où (à peu près), tous les deux sont justes et expriment la même idée :)
        
        [^] # Re: Exemples concrets?
        
        Posté par El Titi le 01 mai 2019 à 21:21. Évalué à 7.
        
        En te lisant, je suis resté commun con.
      - [^] # Re: Exemples concrets?
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 30 avril 2019 à 23:50. Évalué à 2.
        
        Merci Kantien, ça me semble plus clairement posé que mon résumé :)
        
        Quand tu écris ceci:
        
        type patch type state val commit : patch -> state -> state val merge : state -> state -> state
        
        J'ai juste un doute sur les deux dernières lignes: commit et merge sont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?
        
        Pour essayer d'exprimer avec les conventions mathématiques dont j'ai un peu plus l'habitude (style f(x,y) = z avec les préfixes des arguments leur type):
        
        commit(patch: x, state: A) = state: B merge(state: A, state: B) = state: C
        
        L'idée d'illustrer avec des opérations simples (multiplication et ppcm) sur les nombres est très bonne aussi.
        
        Pour la phrase suivante:
        
        La solution est de prendre un type plus riche que les liste pour les sommets du graphe : à savoir des graphes de lignes (dont les listes sont un cas particuliers).
        
        Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).
        
        [^] # Re: Exemples concrets?
        
        Posté par barmic le 01 mai 2019 à 01:45. Évalué à 4.
        
        De ma petite vision de gars qui joue un peu avec la syntaxe d'haskell, la représentation du profile des fonctions avec pleins de flèches vient du fait que ça représente mieux la currification. Commit n'est pas forcément une fonction à 2 arguments qui prend un état, un patch et te donne un état, ça pourrait très bien être une fonction qui prend un patch et te rend une fonction qui elle prend un état et qui retourne un état.
        
        Ça signifie qu'il n'y a pas de différence entre ces deux types :
        
        state commit(patch, state) std::function<state (state)> commit(patch)
        
        [^] # Re: Exemples concrets?
        
        Posté par kantien le 01 mai 2019 à 14:40. Évalué à 5. Dernière modification le 01 mai 2019 à 14:43.
        
        J'ai juste un doute sur les deux dernières lignes: commit et merge sont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?
        
        Plus ou moins. La réponse de barmic est plus proche de la vérité, et c'est effectivement une pratique courante en programmation fonctionnelle (connue sous le nom de curryfication). Si j'écris le type de commit avec des parenthèses, cela donne :
        
        val commit : patch -> (state -> state)
        
        C'est une fonction qui prend un patch et retourne une fonction des états dans les états. Pour prendre une notation utilisée en mathématiques, il faudrait prendre la notation indicée. commit décrit une famille de fonctions indexées par des patchs. Ce qui correspond bien à ce qu'exprime le diagramme :
        
        Les flèches entre sommets sont des transformations indexées par des patchs. Lorsque j'ai écrit :
        
        A = commit p O
        
        il faudrait lire (en rajoutant des parenthèses) :
        
        A = (commit p) O
        
        soit la fonction commit p appliquée à O, ou avec des indices :
        
        De la même manière, une suite de fonctions $(f_{n})_{n \in \mathbb{N}}$ des réels dans les réels a pour type nat -> real -> real.
        
        Il y a bien une correspondance entre cette approche à la Curry et celle où les fonctions prennent un couple. Elle traduit cette égalité algébrique :
        
        L'exponentiel de l'exponentiel est égale à l'exponentiel du produit. C'est liée à l'algèbre des types : là où le produit cartésien correspond au produit, le type des fonctions correspond à l'exponentiel.
        
        Si un type A a 2 éléments et un type B a 3 éléments, alors le type A -> B a 3^2 = 9 éléments (A -> B = B ^ A).
        
        Pour en revenir à la fonction commit, elle associe chaque patch à une fonction des états sur eux-mêmes. Lorsque l'on dit que l'on applique un patch, c'est un abus de langage, en réalité on applique la fonction associée au patch via commit. Et lorsque l'on dit que les patchs sont associatifs, c'est parce que la composition de fonctions est associative. En notant . la composition de fonction on a les égalités :
        
        (commit r . commit q) . commit p = commit r . (commit q . commit p) = commit r . commit q . commit p
        
        Ce qui revient à « appliquer » les patchs dans l'ordre p, q, r.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Exemples concrets?
        
        Posté par kantien le 02 mai 2019 à 11:24. Évalué à 6. Dernière modification le 02 mai 2019 à 11:26.
        
        Un petit complément auquel j'ai pensé après coup.
        
        Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).
        
        Pour le terme de graggle, il semble être propre à Joe Neeman : Pierre-Étienne Meunier ne le connaissait pas. En revanche, un point sur lequel je n'ai pas insisté est que ces graphes de lignes étaient inéluctables pour résoudre la question : qu'est-ce qu'une fusion ? C'est parce que les autres systèmes n'ont pas de définition claire de cette notion qu'ils leur arrivent de se prendre les pieds dans le tapis (comme dans l'exemple donné avec git, où le problème viens de l'agorithme three-way merge si j'ai bien compris).
        
        Revenons un instant sur nos graphes :
        
        On a par exemple une flèche entre les sommets O et A marquée par un patch p. Je dirais que A est un descendant de O par la relation p. Si on prend par exemple des entiers pour sommets, comme dans mon premier commentaire, on dira que 2 est un descendant de 1; ou bien que 6 est un descendant commun de 2 et 3.
        
        Maintenant prenons le graphe qui illustre la propriété fondamentale de la fusion de deux états :
        
        Dans le cas des entiers, je prenais pour fusion le ppcm. Ce qui importe dans le ppcm ce n'est pas qu'il soit le plus petit des multiples communs, mais que tout multiple de A et B soit aussi un multiple de leur ppcm M. Autrement dit : parmi tous les descendants de A et B, il y en a un qui est un ancêtre commun de tous les descendants. C'est cette propriété qui caractérise la fusion.
        
        Dans le cas où l'on travaille sur des fichiers, lorsqu'il y a conflit, c'est cet état de conflit qui est l'ancêtre commun de tous les états futurs du dépôt. Or, pour le représenter, il faut utiliser un graphe de lignes. Et, ce qui est le plus important, lorsque l'on l'on travaille avec des graphes un tel descendant commun existe toujours et c'est lui que l'on appelle la fusion. Mais, ce qu'il y a de pire avec les autres systèmes, c'est que faute d'une telle définition formelle de la fusion ils ne choisissent pas toujours un tel descendant même s'il existe sans conflit (voir l'exemple de pmeunier).
        
        Enfin, comme un état de conflit est un sommet comme les autres dans le graphe de l'historique, résoudre un conflit revient à lui appliquer un patch pour le ramener sur état similaire à une liste, i.e un fichier normal, et pijul garde en mémoire tant l'existence du conflit que sa résolution.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
- [^] # Re: Exemples concrets?
  
  Posté par flan (site web personnel) le 12 mai 2019 à 10:19. Évalué à 4.
  
  On m'a donné ce lien qui donne un exemple simple de fusion qui foire avec svn et qui fonctionne avec darcs.
  Si je comprends bien, il devrait être valide avec git et Pijul.
  
  https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good-semantics.html
  - [^] # Re: Exemples concrets?
    
    Posté par pmeunier le 12 mai 2019 à 22:19. Évalué à 1.
    
    Non, c'est justement un exemple où Git ne marche pas, mais Pijul oui.
    - [^] # Re: Exemples concrets?
      
      Posté par flan (site web personnel) le 12 mai 2019 à 22:21. Évalué à 3. Dernière modification le 12 mai 2019 à 22:26.
      
      Je voulais dire que l'exemple était toujours valide en remplaçant svn par git et darcs par Pijul ;) (donc que git se plante vu qu'il utilise le même algorithme que svn mais pas Pijul qui ressemble à Darcs)
      - [^] # Re: Exemples concrets?
        
        Posté par pmeunier le 12 mai 2019 à 23:17. Évalué à 1.
        
        En effet, désolé pour le malentendu.
        
        [^] # Re: Exemples concrets?
        
        Posté par flan (site web personnel) le 13 mai 2019 à 07:09. Évalué à 2.
        
        Quand je me suis rendu compte de l’ambiguïté, il était trop tard pour changer :(
# Gros besoin de vulgarisation dev technique

Posté par Maxzor le 28 avril 2019 à 19:51. Évalué à -2.
Bonjour, définitivement intéressé depuis plus d'un an, ma compréhension du projet n'a pas avancé d'un pouce et je trouve léger de se repointer avec trois lignes de post et une doc officielle honnêtement indigne. Il vous faut un vulgarisateur, je comprends que Pierre-Etienne a la tête dans les mathématiques et le code… on peut pas tout faire.
- pourquoi une ligne "ghostée" ne peut pas être "déghostée"? Dire "je remets un truc que j'avais supprimé" a de la valeur pour moi, c'est ce qui m'avais intéressé quand on passait sous git les textes de loi avec le bureau ouvert de l'assemblée nationale.
- git est orienté état, mais stocke des deltas dans les packfiles. pijul est orienté delta, mais pour la performance vous devez bien stocker des états non?
- vous utilisez les hard links comme le fait git?
- dans les entrailles de git il y a le staging, la base git et le reflog… dans pijul il y a quoi à côte des graggles et de sanakirja? (Dans les entrailles de pijul il y a quoiiii!! sans avoir à lire du rust :D! Le blog de Joe Neeman est pas mal mais largement insuffisant et daté.)
- votre fonction de hash?
- en quoi l'orienté delta de darcs et surtout pijul est une amélioration par rapport aux VCS précédents qui ont eu la même approche (j'avais lu que SVN est orienté delta?)? Bref une histoire en 10 tomes avec delta/état, centralisé/distribué, numéros de versions/hashs… des VCS serait plus que bienvenue.
- des benchmarks de performance et scaling entre VCS svp!
La lecture des commentaires, surtout sur les patchs taggés sémantique et la théorie math était intéressante.
Très bonne continuation!
- [^] # Re: Gros besoin de vulgarisation dev technique
  
  Posté par pmeunier le 28 avril 2019 à 20:21. Évalué à 9.
  je trouve léger de se repointer avec trois lignes de post et une doc officielle honnêtement indigne
  
  … mais quand même tous les algos qui marchent, pour la première fois !
  
  Tant qu'il y avait des montagnes de bugs que j'étais à peu près le seul à pouvoir attaquer, et qu'on ne savait pas que ça pouvait marcher complètement, la doc n'était pas vraiment une priorité (mais elle est quand même là, le manuel n'est pas indigne).
  
  En plus, comme Pijul est un projet open source, on peut contribuer au manuel si on n'en est pas satisfait ;-)
  
  pourquoi une ligne "ghostée" ne peut pas être "déghostée"? Dire "je remets un truc que j'avais supprimé" a de la valeur pour moi, c'est ce qui m'avais intéressé quand on passait sous git les textes de loi avec le bureau ouvert de l'assemblée nationale.
  
  pijul rollback fait exactement ça, en produisant un patch qui annule les effets d'un autre.
  
  git est orienté état, mais stocke des deltas dans les packfiles. pijul est orienté delta, mais pour la performance vous devez bien stocker des états non?
  
  Il y a deux sujets, l'implémentation et les concepts. En vrai, je pense que tout système de contrôle de versions stocke ou utilise les deux à un moment ou à un autre (y compris Dropbox et Rsync). Même par mail on fait parfois les deux.
  
  Dans Pijul, on stocke des diffs et des états (c'est la principale innovation par rapport à Darcs), mais l'utilisateur n'a absolument jamais besoin d'y penser. Git stocke des diffs et des états (et montre parfois les deux), mais l'objet auquel on doit penser quand on l'utilise est l'état.
  
  vous utilisez les hard links comme le fait git?
  
  Oui, pour "copier" des patchs quand on clone localement. En parlant de ça, je t'encourage aussi à regarder le design de Sanakirja, qui permet de cloner une "base de données" (dictionnaire clef-valeur) sur le disque sans rien copier.
  
  dans les entrailles de git il y a le staging, la base git et le reflog… dans pijul il y a quoi à côte des graggles et de sanakirja? (Dans les entrailles de pijul il y a quoiiii!! sans avoir à lire du rust :D! Le blog de Joe Neeman est pas mal mais largement insuffisant et daté.)
  
  J'ai commencé à documenter ça : https://pijul.org/manual/format.html
  
  Mais Pijul a un fonctionnement un peu différent de Git, en particulier les structures de données sont plus tordues, et il est donc plus difficile d'y accéder sans… faire un peu de Rust. Ce n'est pas un "mauvais choix de design", c'est un peu une nécessité. Il y a malheureusement un compromis entre la lisibilité des structures de données et la complexité algorithmique des opérations dessus. Ceci dit, on a déjà réfléchi à refactoriser le backend pour le généraliser à des trucs moins efficaces mais plus lisibles (on n'a malheureusement pas de ressources en temps infinies).
  
  Le manuel est aussi open source, il est possible de faire des commentaires (https://nest.pijul.com/pijul_org/manual/discussions/) et de contribuer. On a toujours répondu à toutes les questions qui nous ont été posées sur https://discourse.pijul.org, et presque toujours à celles posées par IRC (irc.freenode.net, #pijul).
  
  votre fonction de hash?
  
  Je suis un peu étonné par cette question, pourquoi c'est important ?
  
  Pour l'instant il n'y en a qu'une implémentée, c'est SHA2-512 (si je me souviens bien), mais on peut la changer très facilement en restant rétro-compatible. On risque de changer la façon de l'utiliser dans les noms de fichiers, parce que les préfixes du base58 (ce qu'on fait aujourd'hui) du hash binaire ne sont pas des base58 des préfixes du hash binaire.
  
  en quoi l'orienté delta de darcs et surtout pijul est une amélioration par rapport aux VCS précédents qui ont eu la même approche (j'avais lu que SVN est orienté delta?)? Bref une histoire en 10 tomes avec delta/état, centralisé/distribué, numéros de versions/hashs… des VCS serait plus que bienvenue.
  
  SVN n'est pas du tout orienté delta, c'est (c'était?) un genre de Git où (commit+push) est une seule opération, que tu ne peux pas séparer. Bien sûr, tous les pushs sont fast-forward (comme dans Git).
  
  L'amélioration numéro 1 c'est d'obéir à une théorie mathématique qui garantit des propriétés intuitives dans 100% des cas. Le seul autre système basé sur des diffs que je connaisse est Darcs (que j'aime beaucoup), et il gère très mal les conflits (mais les détecte très élégamment).
  
  des benchmarks de performance et scaling entre VCS svp!
  
  On n'en est pas encore là, on vient tout juste d'avoir des algos corrects. Avant de pouvoir benchmarker, on doit encore :
  1. Améliorer l'utilisation du disque, et mieux gérer les gros fichiers binaires (pas évident, mais j'ai des idées).
  2. Restreindre pijul record et pijul diff pour qu'ils ne regarde pas les fichiers dont la date n'a pas été modifiée (ça c'est facile)
  Encore une fois, on est preneurs de bonnes volontés pour nous aider !
# Patchez moi !

Posté par El Titi le 29 avril 2019 à 20:56. Évalué à 3. Dernière modification le 29 avril 2019 à 20:59.

Bonjour,

Je suis peut-être ici le seul ignare mais j'ai un peu du mal à saisir cette arithmétique des patchs car je ne trouve nul part dans la doc la définition de ces patchs que Pijul manipule.

Pour moi un patch, (hormis la syntaxe du diff pour un cas simpliste), c'est
file.c:
+1, "blabla"

et mon fichier file.c contient:

blabla

si je rajoute:
file.c:
+1, En voilà du
+3, Et patati et patata

J'obtiens

En voilà du
blabla
Et patati et patata

Si je commute les patchs, j'obtiens

blabla

Et patati et patata

Pourrais-tu donner un exemple concret d'un patch avec Pijul ?
Parce que A et B ça ne me parle pas du tout.
- [^] # Re: Patchez moi !
  
  Posté par pmeunier le 30 avril 2019 à 02:08. Évalué à 6. Dernière modification le 30 avril 2019 à 02:12.
  Pour moi un patch, (hormis la syntaxe du diff pour un cas simpliste), c'est
  file.c:
  +1, "blabla"
  
  C'est (à peu de choses près) la même chose dans Pijul.
  
  Si je commute les patchs, j'obtiens
  
  Ah oui, sauf que là tes deux patchs ne sont pas productibles en parallèles. La règle dans Pijul, c'est que tu peux commuter deux patchs si et seulement si tes deux patchs sont productibles indépendamment. Ici, ton second patch dépend du premier, parce qu'il touche à des lignes voisines.
  
  Pourrais-tu donner un exemple concret d'un patch avec Pijul ?
  
  Je pense que ton exemple était déjà un bon exemple. Un autre exemple (que Git ne sait pas commuter) est l'exemple de deux patchs qui touchent à deux fichiers différents, ou à deux morceaux du même fichier, mais séparés par au moins une ligne.
  
  Par exemple, après tes deux patchs:
```
En voilà du
blabla
Et patati et patata
```
  Si Alice décidait d'écrire En voici du sur la première ligne, et Bob décidait d'écrire Et ron et ron au lieu de Et patati et patata, alors Alice et Bob pourraient appliquer leurs deux patchs dans n'importe quel ordre, ça donnerait le même résultat.
  
  Pijul n'est rien de plus qu'un système qui permet de détecter les cas où l'ordre n'a pas d'importance, et qui sait calculer des inverses de patchs. Ce n'est que ça. Les autres systèmes ne savent pas faire ce truc qui a pourtant l'air tout bête, et nous on sait faire (en vrai ce n'est pas facile si on veut un truc qui marche dans 100% des cas).
  
  Ce qu'on fait est tout-à-fait simple. Bien sûr, on peut en parler avec des tas de maths compliquées, et on doit en parler avec des maths pour certifier qu'il n'y aura absolument jamais de problème, mais à la fin ce n'est que ça (et c'est aussi pour ça qu'on a du mal à l'expliquer, parce que les systèmes existants ont habitué les gens à s'attendre à beaucoup plus compliqué pour simuler ça).
  - [^] # Re: Patchez moi !
    
    Posté par barmic le 30 avril 2019 à 07:36. Évalué à 3. Dernière modification le 30 avril 2019 à 07:36.
    
    Ah oui, sauf que là tes deux patchs ne sont pas productibles en parallèles. La règle dans Pijul, c'est que tu peux commuter deux patchs si et seulement si tes deux patchs sont productibles indépendamment. Ici, ton second patch dépend du premier, parce qu'il touche à des lignes voisines.
    
    Cette terminologie m'avait déjà gênée plus haut parce que je sentais que je ne la comprenait pas. La paire de patch qu'il décrit peuvent être produit en parallèle, c'est un fait. Au moment du regroupement de ces commits il faudra définir l'ordre c'est ça ? Et à ce moment là l'historique de mon code devient quelque chose comme {A, B, C->D, E} pour que A, B et E soient non ordonnés mais C et D dans un ordre bien défini car non commutables (non productible en parallèle dans votre terminologie) ?
    - [^] # Re: Patchez moi !
      
      Posté par pmeunier le 30 avril 2019 à 09:16. Évalué à 4.
      
      La paire de patch qu'il décrit peuvent être produit en parallèle, c'est un fait.
      
      Un truc caché dans cette notation des patchs, c'est le contexte dans lequel tu insères. Quand tu dis "+1 blabla", le "+1" fait implicitement référence aux lignes autour, il veut dire "après 0 et avant 2".
      
      Donc le premier patch va faire référence à 0 et 2, si elles existent (ici 0 existe, c'est le fichier, et 2 n'existe pas).
      
      Le deuxième patch fait référence à 0, 2 et 4. La ligne 4 n'existe pas, mais la ligne 2 oui.
      
      Donc non, ces deux patchs ne pourraient pas être produits indépendamment en parallèle, parce que l'auteur du deuxième patch a besoin de connaître la ligne 2.
      
      Au moment du regroupement de ces commits il faudra définir l'ordre c'est ça ?
      
      Dans Pijul, l'ordre est automatique, et le reste de ta phrase est correct. En pratique, les patchs ne vivent pas vraiment dans un ensemble abstrait. L'utilisateur peut les voir comme ça, mais ils ont bien été appliqués au dépôt dans un certain ordre (qui peut varier parfois).
  - [^] # Re: Patchez moi !
    
    Posté par El Titi le 01 mai 2019 à 21:46. Évalué à 2. Dernière modification le 01 mai 2019 à 21:46.
    
    Si Alice décidait d'écrire En voici du sur la première ligne, et Bob décidait d'écrire Et ron et ron au lieu de Et patati et patata, alors Alice et Bob pourraient appliquer leurs deux patchs dans n'importe quel ordre, ça donnerait le même résultat
    
    Désolé je ne saisis toujours pas. Lorsque tu parles de commuter des patchs en //, tu veux dire dans le cas d'un rebase ?
    Par exemple, si les 2 rebasent chacun de leur coté ? (un criss cross rebase ?)
    Avec git, on obtient aussi le même résultat. Je ne vois toujours pas l'intérêt de cette commutation.
    - [^] # Re: Patchez moi !
      
      Posté par pmeunier le 01 mai 2019 à 22:30. Évalué à 5.
      
      Désolé je ne saisis toujours pas. Lorsque tu parles de commuter des patchs en //, tu veux dire dans le cas d'un rebase ?
      
      Peut-être y a-t-il un problème de vocabulaire. Quand je dis "les patchs commutent", ça ne veut pas dire qu'on doit les faire commuter manuellement, ça veut dire qu'on peut toujours les appliquer dans le désordre, et que ça n'a aucune importance, dans 100% des cas.
      
      (les mots en gras sont importants).
      
      Avec git, on obtient aussi le même résultat. Je ne vois toujours pas l'intérêt de cette commutation.
      
      Même sur ce petit exemple simplifié, ce n'est déjà pas clair, parce que le rebase change l'identité des commits, HEAD peut être différent chez Alice et chez Bob, et la suite du travail génèrera de faux conflits qu'il faudra résoudre manuellement. Par contre, je suis d'accord que l'effet immédiat sur le texte, dans les cas où les heuristiques de Git arrivent à se rendre compte que les commits commutent (ça a de grandes chances d'être le cas ici, je n'ai pas essayé), est le même.
      
      Dans le cas général, c'est encore plus faux, par exemple s'il y a des conflits, ça ne fait pas forcément la même chose (ne serait-ce que parce qu'il faut résoudre le conflit pour que Git accepte de rebaser).
      
      Dans les deux cas, ça demande une opération manuelle consciente, alors que Pijul le fait automatiquement dans 100% des cas. Même si je suis d'accord que git rebase n'est pas très dur dans les cas simples, il faut quand même prendre le temps de réfléchir aux conséquences, à la disposition des branches, à ce qu'on veut faire après, etc. avant de le faire, ce qui peut engendrer (en tout cas dans mon propre travail) des pertes de temps d'autant plus importantes que la deadline est proche et que le vrai objectif du projet (qui n'est que rarement d'utiliser Git) est difficile.
  - [^] # Re: Patchez moi !
    
    Posté par InfoLibre le 12 mai 2019 à 10:41. Évalué à 1.
    
    Si c'est compliqué, Pijul sera difficile à faire passer.
    - [^] # Re: Patchez moi !
      
      Posté par batisteo le 14 mai 2019 à 17:46. Évalué à 2.
      
      Il fallait la faire. J’ai honte de ne pas y avoir pensé.
    - [^] # Re: Patchez moi !
      
      Posté par El Titi le 14 mai 2019 à 18:21. Évalué à 2.
      
      Tu bloubes :D
      
      https://linuxfr.org/users/benoit_in/journaux/pijul-un-nouveau-gestionnaire-de-source#comment-1714073
# git et patches

Posté par CrEv (site web personnel) le 10 mai 2019 à 16:47. Évalué à 4.

De manière beaucoup plus limitée je pense, il m'arrive d'utiliser StGit.

StGit is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of Git. These operations are performed using Git commands and the patches are stored as Git commit objects

Pour ceux qui ne voient pas bien l'intérêt de la gestion de patches, faire quelques essais avec StGit peut être une façon simple de voir ce que ça donne.

Dans mon workflow classique, j'utilise beaucoup rebase (avec autosquash). Il m'arrive fréquemment de réordonner mes commits, d'en squasher plusieurs, ou de faire des git commit --fixup.
Avec StGit beaucoup moins, si je veux corriger/améliorer/modifier un changement, je me place sur ce changement (j'enlève tout ce qui est au dessus), je met à jour mon changement, et j'applique de nouveau les autres changements. C'est vraiment plus simple je trouve.
# Intuitif

Posté par matteli le 13 mai 2019 à 16:51. Évalué à 1.

J'étais passé à côté de cette dépêche. Heureusement qu'elle a été remise en manchette.

Je trouve l'utilisation des patchs comme base d'un système de gestion de version, en effet, très intuitif.

D'où les questions suivantes :

D'après vous, pourquoi Linus Torvalds n'a pas utilisé ce concept pour git ? et plus généralement qu'en pense-t'il ?
- [^] # Re: Intuitif
  
  Posté par pmeunier le 13 mai 2019 à 18:23. Évalué à 2.
  D'après vous, pourquoi Linus Torvalds n'a pas utilisé ce concept pour git ?
  
  Je ne sais pas, mais il y a plusieurs bonnes raisons :
  - SVN et CVS avaient le même genre de concepts de développement "séquentiel", et la plupart des développeurs savaient les utiliser. Git l'a juste rendu plus simple et (presque) distribué.
  - Faire un prototype de Git n'est pas très dur, une fois qu'on a les bonnes idées (qui étaient déjà dans l'air, Torvalds a aussi ajouté quelques trucs nouveaux).
  - Darcs avait de gros problèmes de performance. Avant Darcs 2 (2008), c'était catastrophique. Avant Pijul (proto en 2015, version qui marche en 2019), on ne savait pas si on pouvait faire un système basé sur des patchs plus efficace qu'exponentiel dans le pire cas.
  Torvalds connaît Darcs et Pijul. Il voyait Darcs comme une bêtise purement académique (à cause des performances), mais n'a rien contre Pijul.
  
  Je ne crois pas que lui ou nous pensent que Git et Pijul doivent être concurrents, ils ne servent pas vraiment à la même chose.
  - [^] # Re: Intuitif
    
    Posté par reno le 14 mai 2019 à 10:12. Évalué à 4.
    
    D'après vous, pourquoi Linus Torvalds n'a pas utilisé ce concept pour git ?
    
    Je rappelle que Linus a codé le coeur de git en 15j quand il y a eu le clash avec le créateur de BitKeeper donc il a cherché une solution qui fonctionnerait rapidement (dans tous les sens du terme d'ailleurs).
    
    Je ne crois pas que lui ou nous pensent que Git et Pijul doivent être concurrents, ils ne servent pas vraiment à la même chose.
    
    Alors là je ne comprends pas, je pensais que Pijul était un DVCS comme git, pourquoi tu dis qu'ils ne servent pas vraiment à la même chose??
    - [^] # Re: Intuitif
      
      Posté par pmeunier le 14 mai 2019 à 12:24. Évalué à 1.
      Je rappelle que Linus a codé le coeur de git en 15j
      
      C'est exactement ce que j'ai dit dans mon commentaire précédent.
      
      Alors là je ne comprends pas, je pensais que Pijul était un DVCS comme git, pourquoi tu dis qu'ils ne servent pas vraiment à la même chose??
      
      Git est un système de fichiers distribué adressable par le contenu, alors que Pijul est un outil d'édition de fichiers asynchrone.
      
      Les deux peuvent être utilisés comme DVCS, mais j'utilise :
      
      Pijul (et encore un peu Darcs) quand je veux travailler avec des gens et qu'on a le choix.
      
      Git quand je veux faire des sauvegardes horodatées, et avoir des tags automatiques de chaque version.
      
      Quand je travaille sur de très gros projets (NixOS), Pijul n'est pas encore assez efficace, et est encore un peu gourmand en espace disque. Ça devrait s'améliorer rapidement.
      - [^] # Re: Intuitif
        
        Posté par ZeroHeure le 14 mai 2019 à 13:00. Évalué à 3.
        
        C'est exactement ce que j'ai dit dans mon commentaire précédent.
        
        À mon avis, ta grande connaissance des outils te fait écrire des réponses un peu abstraites pour beaucoup d'entre nous, car littéralement tu n'as pas dit ça, donc il faut analyser ton commentaire précédent pour bien comprendre.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Intuitif
        
        Posté par pmeunier le 14 mai 2019 à 14:35. Évalué à 1.
        
        Effectivement, je me suis contenté de ma mémoire (apparemment défaillante) pour savoir ce que j'avais dit.
        J'aurais du relire, au temps pour moi.
    - [^] # Re: Intuitif
      
      Posté par Matthieu Moy (site web personnel) le 14 mai 2019 à 14:59. Évalué à 4.
      
      Il faut aussi garder en tête que Linus n'est pas spécialiste de la gestion de version, et n'a jamais prétendu l'être. Ce qu'il a fait, c'est regarder les solutions existantes en 2005, et voir ce qu'il pouvait trouver qui réponde à son besoin particulier. Sur les systèmes orientés patchs, à ma connaissance il n'y avait que darcs, et il n'avait aucune chance de passer à l'échelle d'un projet comme Linux. Le truc qui s'approchait le plus de ce qu'il cherchait était monotone, il a aimé les concepts mais pas l'implem (trop lente), donc il a recodé Git à partir de rien en utilisant les mêmes concepts fondamentaux que monotone (orienté snapshot, stockage adressé par le contenu, checksum chaînés, …).
      
      Linus a été très bon pour coder un système efficace, et pour le populariser en le rendant utilisable sur un projet phare très rapidement (ce n'est pas donné à tout le monde de prototyper un truc en 15 jours sur un projet annexe et d'avoir des dizaines de millions d'utilisateurs et une boîte qui se vend des milliards basée sur la techno dix ans plus tard !). Mais pour inventer un système conceptuellement différent, Linus n'aurait clairement pas été la bonne personne.
      - [^] # Re: Intuitif
        
        Posté par Maxzor le 14 mai 2019 à 15:08. Évalué à 1.
        
        Oui je me rappelle avoir lu que pour lui les deux choses les plus chiantes au monde en informatique sont les VCS et les bases de données :)
      - [^] # Re: Intuitif
        
        Posté par El Titi le 14 mai 2019 à 15:15. Évalué à 2.
        
        Il y avait Bitkeeper aussi.
        En plus c'est un open source. A merde, ça s'est venu 10 ans après !
      - [^] # Re: Intuitif
        
        Posté par El Titi le 14 mai 2019 à 15:18. Évalué à 2.
        
        Tu es sûr pour monotone ?
        
        Il se rapproche quand même plus de Mercurial qui l'a inspiré.
        
        Il me semblait que c'était Arch de Tom Lord.
        
        [^] # Re: Intuitif
        
        Posté par Matthieu Moy (site web personnel) le 14 mai 2019 à 20:25. Évalué à 3.
        
        Tu es sûr pour monotone ?
        
        https://lkml.org/lkml/2005/4/6/121 « PS. Don't bother telling me about subversion. If you must, start reading
        up on "monotone". That seems to be the most viable alternative »
        
        puis :
        
        https://lkml.org/lkml/2005/4/8/9 « I've worked on it (and little else) for the last two days. »
        
        Il se rapproche quand même plus de Mercurial qui l'a inspiré.
        
        Première annonce de Mercurial : https://lkml.org/lkml/2005/4/20/45, c'est un peu moins de 2 semaines après le deuxième mail de Linus ci-dessus. Donc soit Linus a une machine à voyager dans le temps, soit c'est Monotone qui a inspiré à la fois Git et Mercurial ;-).
        
        Et ce n'est pas une coïncidence complète si les deux outils nés suite au clash avec BitKeeper ont des noms qui se traduisent respectivement en « abruti » et « lunatique » ;-).
        
        Il me semblait que c'était Arch de Tom Lord.
        
        tla (Tom Lord Arch) était déjà mourant à l'époque, je ne suis même pas sûr que Linus l'ait regardé. tla avait déjà été forké en Bazaar (version écrite en C, baz) par Canonical, puis abandonné au profit de Bazaar (celui écrit en Python, bzr), et que ce soit tla, baz ou bzr, aucun ne tenait la comparaison avec ce que Linus voulait en terme de performance (et ce à quoi il avait déjà goûté avec BitKeeper).
        
        [^] # Re: Intuitif
        
        Posté par El Titi le 14 mai 2019 à 20:51. Évalué à 2.
        
        Il se rapproche quand même plus de Mercurial qui l'a inspiré.
        
        Désolé, je voulais écrire que: "Il (Monotone) se rapproche plus de Mercurial, qu'il a inspiré (Mercurial).
        
        Mais Merci pour le rafraîchissement d moire au sujet de Monotone et Arch.
        
        [^] # Re: Intuitif
        
        Posté par El Titi le 14 mai 2019 à 21:40. Évalué à 2.
        
        tla (Tom Lord Arch) était déjà mourant à l'époque, je ne suis même pas sûr que Linus l'ait regardé.
        
        Pour son usage, non.
        Pour les concepts, Git s'en rapproche beaucoup plus et j'ai l'impression que Linus s'en est inspiré. Avec tla, tu traquais toutes les branches distantes à la manière de git avec ses références.
        (Après, je n'ai jamais vraiment creusé le fonctionnement de Bitkeeper, donc c'est peut-être de là que ça vient)
        
        Monotone fonctionne à la manière de Hg. On a une unique branche qui à un instant donné et elle peut avoir plusieurs heads de manière indifférenciées.
        Les bookmarks sont apparus bien après pour attirer des utilisateurs habitués à Git.
        
        [^] # Re: Intuitif
        
        Posté par Matthieu Moy (site web personnel) le 14 mai 2019 à 22:58. Évalué à 4.
        
        (Pour info, y'a un peu de code à moi dans tla, et j'étais un des contributeurs principaux de Xtla, une interface pour tla dans Emacs, donc tout ça me rappelle de vieux souvenirs…)
        
        Avec tla, tu traquais toutes les branches distantes à la manière de git avec ses références.
        
        Pas vraiment : avec tla, le stockage était distribué au sens où chacun avait son bout de branche sur son serveur, mais ce bout de branche ne contenait que les patchs de la branche en question. C'était hyper fragile : si l'archive distante disparaissait, tout ce qui était construit dessus devenait plus ou moins inutilisable. Baz avait commencé à ajouter une notion de cache local pour éviter de refaire des accès distants à chaque fois qu'on accédait à un commit. Le principe d'avoir en local toutes les révisions et de pouvoir les identifier avec une référence n'existait pas dans tla.
        
        Et il y avait tout un tas de bizarreries dans tla (genre les branches qu'il fallait absolument nommer foo--bar--1.0, les convention de nommages de ++fichiers ,,inhabituelles, …) que Linus n'aurait jamais imaginé ajouter dans Git à mon avis (ou en tous cas, j'espère ;-) ).
        
        À l'inverse, un peu après que Linus a démarré Git, Tom Lord avait commencé un concurrent qu'il appelait revc et qui était en gros « tla next generation, basé sur les concepts de Git », sauf que ça n'a jamais pris.
        
        Monotone fonctionne à la manière de Hg. On a une unique branche qui à un instant donné et elle peut avoir plusieurs heads de manière indifférenciées.
        Les bookmarks sont apparus bien après pour attirer des utilisateurs habitués à Git.
        
        Mercurial savait faire des branches nommées dans un seul dépôt bien avant l'arrivée des bookmarks. La différence, c'est que dans Mercurial, chaque commit contient le nom de la branche correspondante, alors que les branches Git et les bookmarks font l'inverse : c'est la branche qui sait quels commits elle contient, et les commits n'ont pas l'info.
        
        [^] # Re: Intuitif
        
        Posté par El Titi le 14 mai 2019 à 23:15. Évalué à 2. Dernière modification le 14 mai 2019 à 23:17.
        
        Et il y avait tout un tas de bizarreries dans tla (genre les branches qu'il fallait absolument nommer foo--bar--1.0, l
        
        Je m'ne souviens, c'était imbitable , avec du Perl en plus, je crois me souvenir :)
        Chapeau en tout cas. Tu persévères dans les DVCS. Bientôt contributeur sur Pijul ? ;-)
        
        Mercurial savait faire des branches nommées dans un seul dépôt bien avant l'arrivée des bookmarks.
        
        Oui, dès le début, c'est pour ça qu'ils ont trainé avant d'incorporer ce plugin.
        Mais malgré tout, toutes les heads étaient logiquement liées (une branche est un sous-graphe connexe) alors qu'avec Git c'est la refspec (entre autres) qui assure cette correspondance.
        
        Hormis la commmutation, Pijul est un peu semblable. Une "branche" (une variante) n'est qu'un ensemble de patchs et on n'a pas vraiment de trace de quel repo proviennent les patchs une fois intégrés, hormis l'auteur (et la signature GPG).
        Je trouve ça élégant car c'est assez symétrique mais ça peut être un obstacle à son adoption auprès de utilisateurs habitués à Git.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

Aller plus loin

PUBLICATION JUDICIAIRE